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.
