How should I split MVC models in my PHP app?

Question

I have a PHP site based on a simple MVC principle. I currently have one model file with many functions for getting data from the database. However, it's becoming a little monolithic now so I'd like to split it into separate models. The question is - what's the best way to do this?

Is it a good idea to create a class for each table, so I can return an object or array of objects (say, a list of articles)? Or is it simpler to create objects/arrays on the fly?

Answer 1

It depends :)

I think It's a good idea to create a class for each object (not for each table). For example, If you have tables:

Users(uid, name, ...)
Marriages(h_uid, w_uid)

It will be cool to create only User class with some methods like ->isMarried()

Answer 2

You can use an ORM, like Doctrine.

Answer 3

For PHP, I would create classes based on data usage and access patterns. Have one class that contains a "core" set of functions that are likely used on every hit. Then have one class for each "section" of your app, which would load when needed.

This isn't the "proper" or best object oriented approach, but it keeps the overhead down. Having a class for each object would be great and neat, but PHP has to load and create everything from scratch on every hit. The more files that need to be loaded and objects created, the slower PHP gets.

You shouldn't need to access a dozen different files just to respond to an Ajax call to find out if someone is married.

Answer 4

I would create a Model for each table. A monolithic table is a nightmare to maintain 6 months down the road as you know now.

as far as valya's example: i would create a Users model and a Marriages model with all their usual insert/edit/delete/get functions on top of customized functions like isMarried() where it calls the Marriages model. ie

class UserModel {
    public function isMarried($user_id) {
     return $marriages->findById($user_id);
    }
}

whichever way you decide to go try to keep it simple. simple is better than clever in the long run.

Answer 5

I would step back and look at your application apart from the database for a sec. If the database were never involved, what would your application look like? What would your classes be called? What sort of objects would you have? What would they do? Design your application and then decide how its data should be persisted.

What I'm driving towards, I think, is something more like the class-per-table design mentioned above, though I would turn it around and say it's table-per-class. Design your system, then figure out the best way to represent your data in the DB. Doctrine is a good system for doing this, but you can do it just fine with more manual database steps, as well.

And as for the overhead involved, it really depends on how many different classes you would be instantiating in each request. Yes, you could save overhead by using generic "fetcher" classes that don't really return objects at all (or that return objects that are hodge-podges of a bunch of should-be-separate-objects), but then the argument could be carried through to not using classes of any kind at all. There's definitely extra overhead whenever you use object-oriented programming of any kind, or function libraries, or anything else that you have to include. But the reason we don't have make single-file PHP sites is because the overhead incurred is bearable, and it's much more bearable than the developer overhead incurred by going the other way.