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

Filed under:
|
|
|

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

Related posts about php

Related posts about object-oriented