Structuring models in MVC framework?

I'm wondering if there's a best practice for this, I'm building a site that's going to require quite a few models and I don't want to end up with a unstructured mess. Basically I'm looking for a good rulesheet to structure out the models. Right now I can only think of two ways:

• Every table in the db has its own model, ie. accounts.php, books.php etc.
• A model represents a collection of methods, pertaining to a core module of the开发者_如何学Go website, ie. a login model that contains methods like login, logout etc. a model that handles sessions, a model that handles cookies

Thanks for your time!

I suggest that model != table in general.

Instead, a model represents some component of your application's domain logic. This might correspond one-to-one to a database table sometimes, but it could also be that a model consists of several database tables, or no database tables. And some models could be comprised of a collection of other models. Also some tables may be used in multiple model classes.

The one-to-one relationship between models and tables is attractive for simplifying applications, but it's a type of coupling that can be misleading.

In MVC, the Controller and View are relatively easy and straightforward. They correspond to handling input and generating output. The Model is hard, because this is the rest of your application's data and logic. Welcome to OO design and architecture!

A good resource to learn how to architect models effectively is Domain-Driven Design by Eric Evans, or the free online short version, Domain-Driven Design Quickly.

This cannot be easily answered. Have a look at some of my answers to similar questions

• Data Mapper and Relationships: Implementation strategies?
• How do I write object classes effectively when dealing with table joins?
• OOP design: How to incorporate DB handling into application objects

for some ideas. But basically, all these mainly reference Patterns of Enterprise Application Architecture so you could just as well cut short to them.

^{I am marking this a Community Wiki, since it only references some answers. Feel free to vote on them instead of this answer.}

The model per table is by far the most common way. And I think the cleanest as well. Your second method is going to end up as an unstructured mess.

But I think they both will end up being the same in the end. Because you'll probably only touch one table in the sessions model, and one in the login model, etc.

An ORM like Doctrine can help greatly in keeping things in order, but it does add overhead.

Just remember, the model should be the only part of your MVC structure that speaks with the database and contains the core business logic. As long as you stick to that rule, you are on the right track.

The only think that can cause a mess in your model folder is if your application is getting bigger and bigger and your framework does not allow you to structure the models in subfolders or you wasn't doing this.

Try out ORM. It has very strict rules, so you can't do much wrong in your structure.