Understanding the MVC pattern

In my quest for the perfect code I’ve ran thru many tries since I’ve entered the OOP writing utility classes and even coded my own templating system with a simple wildcard replacing variable system but it lacked into^wflow control^w structures.

Then I’ve had contact with Smarty and PEAR’s DataObject (PHP language) at a company I’ve worked last year when we used a (very primitive and simple) kind of MVC with DO as model layer, Smarty as view layer and only one huge (around 130 KSLOC) controller that we called “The Godfather” as a private joke. After all, besides DO’s memory meanace, (almost) everything worked as it should but only after I’ve worked with CakePHP’s (Ruby’s) MVC implemetation that I realised how everything should behave.

MVC stands for “Model View Controller” and it’s a multi-layered design pattern. It’s one of the most famous (uhhh the flashes!) and organized design patterns I’ve worked so far because you can split the codes from your database calls and templating system.

NOTE: MVC is a design pattern and not language-specific. It can be written in any language and you can even write each layer in a different language since you keep the communication between them.

The principle
The flow behind the MVC pattern relies on the following scene: Imagine a line with three dots. In one end we have the user and the other the server. In the server end, we have the model layer, the database, which holds all the information to be delivered and received to/from the user. In the user end we have the view layer that is the interface that he will read and input the information. The “decision-maker” is the controller that will make the DB calls and render the interface to the client.

Sorry Oracle, DB2 and other guys that were left out of the schema. I lacked out of space :P

The Model
The model part will be responsible to abstract the database from the rest of the code. On MVC apps it is commom to have in this layer a ORM to ease the coding. Some practices like “Fat Models, Skinny Controllers” defend that we should keep the businesse logic under the model layers to make the controllers “skinny” perfoming only the connection between the other two layers as it should behave.

Wikipedia referes to that as:

The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating whether today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

The View
At this layer we will integrate the data sent by the controller with our layout, mostly often via a templating system so you can keep all the app code from the interface (in case of Web Apps, the HTML, but it could be the GTK in PHP for plataform, Swing in Java or any other). It will place the data at its desired location. I think the very basic feature of a templating system are the variables on the interface body that are replaced by text sent by the core (templating system’s/view’s) and most of the existing ones has flow control structures too. I strongly advice to use existing code except for very particular cases.

The Controller
He will be responsible by making all the calls to the database and retreiving to the user thru de view layer. For example, your file will have only a call to the controller and he will make the necessary calls to the other guys. He gets the party started! One commom good practice is to have one central controller that will have the commom functions and init functions and then extend one controller class to each model. Each controller method may perform different (or differents) view calls to suit its needs.

The Very Commom Mistake: Overloading
The most commom mistake is to overload the model and view layers with things that shoud be done at the controller. Always have the picture of what which layer is intended for and put all your business rules and calculations on your controllers. As Alvaro suggested at the comments, put your bussines logic under the model or you can opt to use other patterns. Remember: At the view only the variables and a few flow controls and the at model put your business logic. Leave the controller to do all the intersection.

This is very commom and may imply in performance downgrade and not staying DRY.

The Very Commom Mistake: Thinking MVC will fit all your needs.
WRONG! It will fit MOST (or not!) of your needs but as we know, there is no absolute truth, so choose your pattern wisely.

Some systems even use other design patterns along the MVC such as Observers and Singletons sub-apps.