In the last post of this series I covered some basic groundwork on the MVC architecture. I briefly went over the three layers and what the role of each one is in an application. In this post I intend to give a more in-depth overview of the model.
All the concepts of the MVC architecture cannot be covered in a few blog posts. Many books have been written about MVC and entire books have been written just covering the model. If you haven’t built an application based on MVC before I can give you enough information so that you can get a basic grasp on the model layer.
What is the model?
From Wikipedia: The model is the domain-specific representation of data on which the application operates. The model is where we have all the entities that our application needs and the logic that goes with those entities. Without a good model we only have raw data to work with. The model adds logic to the raw data as well as implementing persistence of the data (often in the form of a database).
The Model is NOT a Database Table Representation
Most MVC frameworks do not provide you with full models. The models they provide you with usually only provide data access. This is not actually an issue as models are application specific. The problem I have with the frameworks is that it is not specifically mentioned that they do not have a full model.
Some frameworks use an Object-relational mapping (ORM) solution such as Doctrine while others use an ActiveRecord pattern or perhaps a table data gateway pattern. This is fine for data access but where does our business logic and domain logic end up.
Business Logic in Controllers
Business logic is the rules that our data has to conform too. As a quick example let’s say we have model for Users. There are probably a few rules you can instantly think of for a User model. You probably want the username to be more then 2 or 3 characters long. You also want the username unique. There’s no point in usernames if two people have the same username. This is business logic and it should not be inside our controllers. We want our controllers to be controllers not validators for our data.
Once we start adding this kind of logic to the controller we start to bloat our controllers and mix the layers. The whole reason we’re using an MVC framework is to separate the layers not combine them.
The last issue with adding this logic to our controller is that we have now made maintaining the application a nightmare. Let’s say our controller has two actions that need the User model. One action is the Register action and the other is Edit or Modify account details. Now we have to add the code that controls what data can be entered for the username in two different parts of our application. This defeats the OOP principle of DRY (Don’t Repeat Yourself). Now when you make a change to your model, username must be minimum 4 charachters and maximum 20 long, you have to change the code in two places instead of just inside your model if you had kept the logic where it should be.
Good Models
Our model should contain our business and domain logic. Our model should also contain our data persistence. Leave the controller to be a controller, shuttling requests back and forth between the view and the model. Adding business logic to controllers makes your application difficult to maintain.
Another aspect of a good model is that it’s framework independent. If you create your model for an application using the Zend Framework and decide for some reason to switch over to Symfony you should be able to drop your model into the Symfony framework without a lot of problems.
Conclusion
By reading this hopefully you’ve got a basic understanding of the model layer. The idea is to decouple the model from the framework into a set of structured classes. Instead of creating Fat Bloated Controllers that contain much of our domain logic we should instead focus on creating Fatter models. In the next post I’m going to get into Domain Driven Design a bit and following that we will dive into the code for our application.
I know this is supposed to be a tutorial on writing application with ZF but I feel that many newer developers don’t understand the model as well as they should so I think it’s time well spent laying some of this groundwork. I’m going to include a bit of a longer list of extra reading as there is a lot to the model.
Extra Reading
- The M in Mvc: Why Models are Misunderstood and Underappreciated
- Model Infrastructure
- On models in a Zend Framework application
- Survive The Deep End: Chapter 3 The Model
- Decoupling models from the database: Data Access Object pattern in PHP
Related posts:
- ZF Tutorial 2 – Model-View-Controller Model-view-controller (MVC). What is it? What does it do? Is...
- ZF Tutorial 1- Introduction Welcome to the Zend Framework Blog application tutorial series. I’m...
Related posts brought to you by Yet Another Related Posts Plugin.
