Table of Contents
Models are an essential part of an MVC application. Models encapsulate the data access layer (such as a database) and a 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). The model also ensures that the data is consistent, by validating it and triggering an error when the application performs an illegal operation.
The model part of an application is sometimes called the domain model. A domain model is a conceptual model of a system which describes the various entities involved in that system and their relationships.
There exists different types of implementation for the domain model. We advocate fat models that encapsulate everything cited above. Some developers might argue that it's OK to have skinny models that aren't much more than a data access layer. They are wrong. Why? You can find some reasons over there. But we have more reasons than that.
Models should be reusable. You should be able to take the domain model (and only the domain model) from an existing project, copy it into a new project, and start using it. There should be no data corruption in case you make a programming error in your new project. If your domain model is well designed, there won't be any.
The domain model contains the building blocks of your application. When developing a web application, the first thing you should do when you start coding is create the domain model. It doesn't make sense to create the view if there's no data to show (unless you're only working on the design). It doesn't make sense to write controllers if they can't work on anything. When your models are written, you've almost finished your application. Everything else will be much easier. Your main concerns after writing the model is to correctly implement your application's workflows and to ensure a great user experience.