ASP.net MVC Framework and what it means for you

By now most of you have probably already heard about the MVC framework that Scott Guthrie announced on his blog about two weeks ago, and if you are anything like me, then you are elated that this is happening. While some other, like the castle project, have already been here before, it is nice to see that we will have a full Microsoft backed framework that we can sell to our places of employment. So, if you are one of those people who has read up on Ruby on Rails, Agile Development, MVC, and thinks that getting rid of the viewstate will be the best thing since sliced bread…then you can stop reading now. Sorry, this post isn't for you. This post is for all of those asp.net developers out there who have heard about that MVC thing, but haven't quite got their heads wrapped around it or for those who mistakenly think that the asp.net framework already implements an MVC pattern.

The asp.net framework is generally developed with what is commonly referred to as a Page Controller. While some people may still be writing all of their business logic in the code behind of the pages, most of us have graduated to a nice n-tier design where all (or at least most) of our business logic is nicely tucked away in business objects. The Page Controller pattern puts all of the program control logic into the hands of the page. This means that a user explicitly calls a page and that page takes the user's request and then decides what to do with it. This ends up creating an architecture that looks like this…

Notice in this highly technical diagram that Jim and Frank and directly calling into the Pages which are the view and the controller. (Well, technically the aspx page is the view and the code-behind is the controller, but this isn't always the case) These pages then call directly into the business layer or, if they need to, they can redirect to other pages. It is this control at the page level that makes life difficult when you are trying to manage a user through multiple page transitions, or if you need to display multiple different pieces of data depending upon how the user got to a page. In asp.net we have a multi-view in order to manage a situation like this, but wouldn't it be great if we actually had multiple views??? Of course it would!

So, here goes MVC, which is made up of three parts, but first lets go to the diagram…

First off notice that there is no direct interaction between the user and the views (and that somehow Jim found a pipe and Frank a trendy hat). This is the most important aspect of the MVC architecture. The user simply calls into a controller and passes a (usually) optional command. The controller looks at this command and decides what to do (this is why they call it the controller). So lets break it down for you…

1) Model: The model is the business and data layer of the application. Some interpret the model as being the database or the actual data store, but this is just not true. The model is the part of your application that represents the data that your application is responsible for.

2) View: The view (of which there are usually man) is the part of your application that renders the data for consumption. In the case of the asp.net MVC framework, the view will be responsible for rendering the HTML out to the browser.

3) Controller: The controller is the important part here, and it the main part that is missing from the asp.net model. The controller is the orchestrator of this whole code symphony. The users call the controllers and pass it commands (or they may just accept a default action the controller specifies) and the controllers can take whatever state or context it has and makes a decision on what view to render. It can then grab data from the model, hand it to the view, and then render the view back to the user.

I hope this helped clear up the whole Model View Controller architecture for some people, and if it didn't, please feel free to leave comments with any questions you may have. As soon as some preview bits of the MVC framework are released I'll be sure to dig in and get some samples back to you as soon as possible.