Thread

There is One Model One Table pattern. One place to look for anything related to corresponding database table.

There is Single Responsibility Principle. Splitting model into several standalone actions.

There is Model As Layer philosophy. Meaning that model is made of three types of structures: Domain Objects (completely unaware of the storage), Data Mappers (only responsible for the storage) and Services (that interact between Domain Objects and Data Mappers).

What do YOU use?

Having so many approaches (and I suppose there are more) I’m having problem even understanding how should I organize Controllers and Models to go with the most convenient solution.

more comment ...

For me most of the time it’s 1 model for 1—something (database table, folder, excel file, etc…)

BUT I also sometimes have a model over 2 or 3 somethings.

So for example I have many dropdown menus in 1 database table but their individual items are in another table (many to one). While both the tables have there individual models. I consider them more like protected models (in a folder named after the “sudo” parent model). My controller/library only talks to the “sudo” parent model which isn’t attached to any specific table but can split and join the data into the 2 separate tables as needed. This way the controller/library doesn’t need to know to much about the way the dropdowns are stored and they are accessed as a single model. I could change the way they are stored (into 3 tables for example) and the code should still work.

Just my 2 cents

Please explain it more

It is an interesting question and I hope more people answer. I tried the 1 model per table but that simply makes no sense to me as I end up with tens of models and loading lots of them. Also joins make this a non starter as far as I can tell.

I tend to group my functions together based on the roles they affect.

examples:
Membership model
For logins and role checking etc.

Email model
For sending and dealing with emails.

Account Model
For dealing with members changing their profiles, account settings etc

Task Model
For adding, querying or editing tasks etc

The membership model usually gets loaded automatically but the others I can then load as and when needed. It is also very easy to see which model contains which bit of code or database interaction. However the drawback is when I need to change a table, which could be referred to in lots of different models, have not found or thought of a way around that yet.

Best wishes,

Paul.

Having so many approaches (and I suppose there are more) I’m having problem even understanding how should I organize Controllers and Models to go with the most convenient solution.

Here’s how I do it, and first, a note about controllers. The standard routing has it so your URL break down to http://www.example.com/controller/method/argument, so how to organize controllers is basically how you organize your application.

If your application requires users to log in, then you’ll also have other user-related functions, so you’ll want a users controller with methods for the other user-related functions. Like this.
http://www.example.com/user/login
http://www.example.com/user/register
http://www.example.com/user/forgot_password

If your application is a retail site that sells books and music, you may want a controller for books and other for music. But also could decide to have a controller called “catalog” and bring both books and music together under it. It’s pretty much a design decision independent of the framework or methodology you’re using. Consider looking into Structured Analysis for some ideas. It’s a shame that the trendiness of OOP has led people to think the older methodologies are not useful, but they actually are.

As far as the relationship between controller and model and between model and database, I use one model per controller, and use as much of the database as I need in the model. Restricting the model to one table isn’t practical. Only the simplest of applications never need to join two or more tables.