Model
The model represents the domain you are trying to model, and also encapsulates the business logic of your application. For example, using the good old blog example, think about all the things your make up your blog: Posts, Comments, Tags, Categories, Authors, Commentors, Editors, Feeds, etc.
This is your domain, and depending on which of those you want to work with in your application, you model them as the M in MVC. For example, you would create a Post model to represent a post that a user makes or a Comment model to represent a comment that a user makes. Most frameworks allow models to have have relationships with other models. For example, a model can 'own' one or more other models, or belong to one or more other models, or both at the same time. These relationships are typically expressed as:
- One-to-One
- The simplest type of relationship, a one-to-one relationship between two models simply says that one model owns the other.
- One-to-Many
- Since your authors create posts, you could reason that your Author model owns many Post models. This is expressed as a one-to-many relationship where your Author model is the one side of the relationship and your Post model is the many
- Many-to-One
- The opposite of the above relationship, one or more Post models belong to one Author model. Here, your Post model is the many side of the relationship and the Author model is the one
- Many-to-Many
- Sometimes, you have the scenario where you want many models to belong to or own many other models. Think about tags on your blog post. You would want to be able to associate many tags with many posts. Therefore, your Post/Tag models have a many-to-many relationship with each other.
Models are where you want your business logic to go. For example, lets say you wanted authors to be able to upload an image along with their posts, but you only wanted images of a certain size/dimension. The business logic for checking the images file size or changing its dimensions would go in the Post model, since that image is a property of the Post model and belongs to it. This leads to the saying that your models should be fat and your controllers skinny. A common mistake that new comers to the MVC pattern make is putting all the business logic in the controller and having empty models that just represent rows in a database (e.g., doing the image re sizing logic in the controller rather than the model).
Normally, you'll interact with databases using an ORM (Object Relational Mapper). If you are using a popular framework like Ruby on Rails, Laravel, Symfony, the ORM typically uses the ActiveRecord pattern. Some would argue that ActiveRecord is a bad pattern because it means that your models are responsible for persisting themselves to the database as well as their own internal business logic. Models don't have to be persisted to the database, but when they are their values are stored a row in a table in a database. They are not the row or even the database as another answer suggests. Typically the model's values will be stored in just one row, but you can (if you really, really want to) store them across multiple rows in different tables/databases. Other frameworks handle this differently. For example in ASP.NET MVC models are not responsible for persisting themselves to the database. Whether one is better than the other is debatable. I use both Rails and ASP.NET MVC and appreciate both approaches where it makes sense (simple applications with simple models ActiveRecord is great). The main problem with the ActiveRecord approach is that your model has to be the same as the table that you are saving it to in your database. If you have a much larger table and you want to extract data from it and map it to a model (think pre-existing/legacy data) becomes tricky.
View
Views are the simplest part to understand, because they are simple by nature. The convention with most MVC frameworks is that your views should be dumb. That is, they should not perform any business logic (that is done by your models, remember?). All they do is receive data from the controller and display in a way that looks nice to the user.
While your view shouldn't be performing business logic, you can have some client side logic in there. For example, if you have a view to display a list of posts or authors, you can use JavaScript to allow users to do things like dynamically change the ordering of the list (without having to make another HTTP request to your application). The point is that they can apply some processing to the data they receive, it should be only for the purposes of displaying the data in a different way, not changing it.
Controller
The controller is the glue that holds your application together. Think of them like the conductor in an orchestra. While they don't actually play any instruments, the orchestra wouldn't be able to function without them. Your controllers are the same. They interpret requests from the user and perform the necessary operations to produce a desired result.
Typically, when your user enters a URL (let us say posts/show/my-first-post) your MVC framework (Rails/Laravel/ASP.NET MVC/whatever) will have a routing engine that will parse the URL and determine the correct controller to invoke. Usually, your URLs will follow some sort of convetion that makes this easy. Let us say you are using a convention where the URL segments relate to {controller}/{action}/{id} where the first segment is the controller to invoke, the second segment is the action on that controller to use, and the third (or however many parameters you wish to pass to the controller) are passed to that controller's action as parameters. So, if you had a post controller with a show action that took one parameter, id the routing engine would pass along the HTTP request to it.
Typically, your controller will invoke a model (which performs some business logic and returns a result) and then passes that result along to the view for your user to see (in the form of a web page).
