A lot of people seem to be slightly confused about what the M and C, Model and Controller, of MVC are, in regards to web applications.
- What does the Model do?
- What does the Controller do?
View is what everyone seems to know, though… I wonder why is that so? What is so confusing about Models and Controllers?
Many people seem to be looking for pre-made “model classes”. Well, there aren’t any.
In practical terms, models are classes (and functions) that deal with data persistence. They fetch data from the DB, they store data in the DB… They generally work with the database – or a text file if that’s where you store your data.
A model can be a class which has hand written SQL queries for working with the database. This is much better than cluttering the queries around other code. You could simply have a class UserModel which has methods such as getUser and saveUser, which just take certain parameters and do something with it.
A more advanced model could be a class which implements the ActiveRecord design pattern: The class describes a row in your database and modifying the classes properties will modify the row in the database. It can be a Zend_Db_* object, an ORM object generated by Propel…
Controller is what deals with processing things. Controller gets some data from the model, might do something with it, and assigns it to the view. It’s the workhorse of the application which does most of the manual work, except accessing the database as that’s the models job.
There are a lot of differing opinions on both models and controllers. If it works with data, it’s a model. There is no “correct” way to do models – opinions differ. One likes hand written SQL, another likes using a fluent PHP interface or ORM classes.
Another thing where opinions differ is if the model should validate or filter data.
In my opinion, it’s much more ideal to perform validation and filtering in the controller. The model, as said earlier, works with the database. It gets some parameters, whatever they are, and uses them to talk with the database. It should not care what the data is more than take measures to prevent SQL injection.
The controller’s job is to perform actual validation and filtering: Check that the data is indeed in the correct format, remove unwanted things such as HTML tags, and then pass it to the model.
Why? Imagine a scenario, where you write a model which validates some data, say user comments in a blog. Now, say it removes HTML tags from the comment text… What if you wanted to let administrators post HTML but not normal users? See how fast it turned into something that your model should not do, namely user access checking. Things like this is why models shouldn’t care much about the data.
- Model models, represents, the data and actions you can do with it.
- Controller controls
In the end, it’s pretty simple, right? Programming just somehow makes things complicated and confusing!