Breaking up a large PHP object used to abstract the database. Best practices?
Posted
by
John Kershaw
on Programmers
See other posts from Programmers
or by John Kershaw
Published on 2012-09-06T09:14:32Z
Indexed on
2012/09/06
9:49 UTC
Read the original article
Hit count: 277
Two years ago it was thought a single object with functions such as $database->get_user_from_id($ID)
would be a good idea. The functions return objects (not arrays), and the front-end code never worries about the database.
This was great, until we started growing the database. There's now 30+ tables, and around 150 functions in the database object. It's getting impractical and unmanageable and I'm going to be breaking it up.
What is a good solution to this problem? The project is large, so there's a limit to the extent I can change things.
My current plan is to extend the current object for each table, then have the database object contain these. So, the above example would turn into (assume "user" is a table) $database->user->get_user_from_id($ID)
. Instead of one large file, we would have a file for every table.
© Programmers or respective owner