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 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 framework already implements an MVC pattern.

The 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…

 Page Controller Drawing

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 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…

Model View Controller-Drawing

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 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 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.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (6)

  1. I would, but the MVC framework for .net is not out yet. In fact, there aren’t even any preview bits available. Currently there are some other MVC frameworks out there, but I don’t have a lot of experience with them. As soon as the MVC framework releases a preview I’ll get some code up on the site.

  2. I need to get super-scientific diagrams like that on my blog. Please tell me that you have some awesome drawing program that allows to to make those drawings and save them directly to your posts.

  3. Khushal, if you check out Monorail you’ll find its programming model very similar to ASP.NET MVC, so that’s a good guide as to what to expect.

    If you want an alternative that runs inside ASP.NET 2.0 today, have a look at jMVC.NET which is an open-source client-side MVC framework. It solves a slightly different problem (dynamic UIs without postbacks or AJAX) but the mindset is the same:

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All