If you work with PHP regularly, chances are you’ve come across an MVC structure at one point or another. They are widely used in many popular frameworks and open source software like OpenCart.
Using an MVC structure for your projects is a great way to separate responsibilities in the code. Simply using an MVC framework doesn’t mean you’re following MVC principles. I’ve seen some positively nightmarish spaghetti code build on Zend that would have taken months to refactor. To follow MVC principles you need to understand what each part of the system is meant to be responsible for. MVC stands for Model, View, Controller, and each part of the structure has a separate responsibility.
The Model
In a web application, the model is typically “the bit that talks to the database”, so it’s often wrongly assumed that that is all the model is meant to do. When people make this assumption what they typically end up with is Fat Controllers. Actually the model is meant to have all the “business logic” of the application. If you need to find a particular date, even if you can do it in the controller, you should be asking the model to do that.
So, we send information to the model from the controller (if you don’t know exactly what the controller is yet, don’t worry, we’ll get there). We tell the model things like “get the last 10 items from the database”, “update the session”, or “figure out the date we need from this information”. The model does those things and updates its state, and it may also update permanent storage (like the database).
The View
The view is the bit that displays information to the user. It will take those last 10 items from the database and the date that the model calculated, and display it. You’ll often see some kind of templating engine plugged in here, and I’m sort of on the fence about using a templating engine. My favourite one of all time is still the adaptation of Smarty used in phpBB, but if the code is only going to be developed by PHP developers, you don’t need a templating engine. I think templating engines are most useful if someone at your company who doesn’t really understand PHP will need to edit the template, so it depends on your needs.
Anyway, my current preference is to give the view files a .phtml extension, to give myself a mental cue that it’s only displaying information.
Something I see way too much of when I’m maintaining other people’s code is the model being passed to the view, and the view interacting directly with the model. Now, depending on the usage this can be fine. But all your “business logic” should be done by now, so the view should only be querying the model for things it’s already worked out. The view should absolutely not be manipulating the model, it should only be displaying information from it, then at this point our application awaits input from the user – like clicking a link, or filling in a form.
The Controller
The controller is the bit that handles the user input. If they clicked a link, or entered a URL, it figures out what information to display based on how it’s been called (typically with the assistance of a router, which I’ll discuss in detail in a future post – but basically a router will call the correct method from a controller, so if someone enters the URL /shoes/showAll/red, then the router’s job is to find the shoes controller, call the showAll method, and send “red” as a parameter). Taking the user’s input, the controller asks the model to set itself up a certain way – like finding all the red shoes.
I mentioned Fat Controllers above, because what tends to happen, particularly with someone who is new to MVC, is that the controller ends up doing everything. This isn’t its job – it asks the model layer to do it, then it’s done.
Let’s take another example – a form is submitted to /shoes/search. The router calls the search method in the Shoes controller. The search method then fetches the $_POST input (sanitizing it as necessary – remember user input is disgusting and dirty and not to be trusted). The tendency from people unfamiliar with MVC here is to get a reference to the database and start querying it. But all we actually want to do in the controller is process the user input and pass it to the model to perform the search.
In Conclusion
I’d like to expand more on this subject in future, but here’s the basics:
- The model is the application’s state, it is responsible for the business logic of the application.
- The view displays the information from the model to the user, and the application then waits for further input.
- The controller takes the user’s input, processes it, and passes it to appropriate methods on the model, to ask the model to modify itself as necessary.
Common pitfalls:
- Avoid making one layer of your application “fat” – the responsibilities should be separated between the layers.
- Don’t manipulate the model from the view – manipulate it from the controller, and then display it from the view.
- Don’t perform database queries and complicated calculations in the controller – pass the necessary information to the model, and perform the “business logic” there.
Questions? Something not right?
If you spot anything in this article that isn’t clear or might be misleading, please leave a comment and let me know so I can correct it!
Recent Comments