With this design for structuring applications garnering such attention, it is becoming more important for people to understand how and why this is being used. I have had a few people ask me questions about MVC. The two questions people ask me about MVC are "What is MVC?" and "How does it help me?" Before anyone tells me this article is too simple or easy, keep in mind I have written this for people who do not know what MVC is. This is really just supposed to be a quick article which can be read quickly and give a person a good understanding of the MVC pattern.

In this article I will be explaining what MVC is and how it can help you develop applications. I will be specifically talking about ASP.NET MVC. The MVC pattern can be used for a lot of different reasons. In a few simple words I will say that MVC is just a different way of structuring an application, and a common reason why someone should use MVC is so that testing becomes easier.

The basic idea with MVC is that the controller is in charge of handling everything. When the view needs data it is the controller's responsibility to pass that data to the view. This means that as its name states, the controller controls things. The view should simply be for viewing things not being concerned with logic. And the model, as its name states, is there to model the data.

The obvious thing to wonder is what the acronym even means. It is not easy to tell. A lot of people know what it stands for, but not what it means. The first thing I want to do is explain this.

We have a few pieces I will be explaining. There is obviously the Model, the View, and the Controller. One piece a lot of people forget about is the infrastructure. This includes any external resources you might access: databases, files, RSS feeds, etc. Even though the acronym goes MVC, for the purposes of this article I will be going View, Controller, and then Model.

View - What

As anyone who has ever tried to test a web application knows, it is difficult to test the UI of an application. It is easy to test a method with few dependencies because you can easily just call the method and check the results. With web pages it is quite difficult since you would need to check what html the page is generating. In the case of MVC, the view is not very different from the web forms version. The difference actually comes in how people use them. These views for the most part need to only know about displaying information. Decisions should not be made on the UI. Those decisions should be made elsewhere. Even decisions which will affect UI should be elsewhere and just called from the View.

View - Why

This is a huge advantage to us because we no longer have much to test in the UI. This makes it a lot easier to test the UI because it is a lot less complicated. This makes our tests easier and also has a lot fewer tests we will need in the UI.

Controller - What

The controller is exactly as its name states. The controller takes control of the site. This is where all of the actions logic exits. Actions which users may take using the site are exactly what you will find in the controller. The pages, which users can view, are in here. Forms around the site will post back to these actions in the controller. This is a lot like what used to exist in the web forms. This logic would be contained in the code behind files of the pages.

Controller - Why

As we mentioned before about the view, user interfaces are hard to test. I have also mentioned that we kept a lot of this logic with the UI in the past. By keeping this completely separate the whole time, we are able to keep the view clean of this logic. The controller is actually pretty easy to test. Actions in controllers receive information from the forms when users post to the site. Thanks to bindings, the methods for the actions take parameters which are used to get the data from the user.

When we test these we can pass in the data we want to test as parameters and we are able to look at the result returned from the controller. This allows us to very easily and effectively test the controller and its actions.

Model - What

The model is the connection between the application and the data in the infrastructure. In the model you will define all of your domain objects. This is where entity classes will exist. These classes will define your data. These will include properties of different types as well as probably some logic specifically for working with these classes.

When data needs to be shown to users, it is obtained in the controller and this modeled data is then passed from the controller to the view. The model is where the application is going to get its data.

Model - Why

It just makes sense to keep the data objects and the logic which works with them separate from the rest of the application. I am sure if you know about unit testing, then you know all about the idea of breaking dependencies. Keeping these objects nicely separated allows you to test them more easily.

The obvious big answer for why things are structured this way is for testability. By restructuring in this way it is much easier to have each piece separate. We have also managed to keep the most difficult part to test (the User interface) as small and lightweight as possible. This means that more of our application can be tested easily. The ASP.NET MVC Framework is designed to make testing easier. This does not mean that you cannot use it even if you do not test. Anyone can use ASP.NET MVC. Enjoy it.