Error getting theme layout

Taking a Dip Into the ASP.NET MVC Framework

Posted @ 9:44 am by Brian Lee | Category: Technology | 0 Comments

Just as I was becoming comfortable playing in the familiar waters of web forms-based ASP.NET applications, Microsoft announced the release of the ASP.NET MVC framework, an alternative to the ASP.NET Web Forms pattern for creating MVC-based Web applications.  According to Microsoft, the ASP.NET MVC framework offers the following advantages:

My first reaction to reading about the ASP.NET MVC Framework was a mixture of excitement, fear, and confusion.  I was excited by the idea of having a new tool to make better designed/engineered web applications; I feared the unknown of a world without web forms and view state; and I was confused by the semantics of MVC.  Wasn’t I already programming using the MVC pattern?

Being the cautious yet curious person that I am, I decided it was time to stick my big toe into the proverbial ocean of the ASP.NET MVC framework.  Thus, my first order of business was to address my confusion over MVC.   Reviewing the definition of MVC seemed like a good place to start (ref.

Wasn’t I already programming using the MVC pattern?  After all, isn’t the ASPX the same as “view,” the code-behind the same as the “controller,” and my data classes the same as the model?  It turns out that the answer to that question is “yes,” but the flavor of MVC pattern programming that I currently employ is not the same as MVC pattern supported by the new ASP.NET MVC framework.  One of the main differences, in my opinion, is in the controller. (There are many other differences, but this one got my attention first.)  ASP.NET web form-based applications use the “Page Controller” pattern, which has a single controller object per page as opposed to the single object for all requests.  Some of the liabilities of using the page controller pattern are the following:

On the other hand, web applications built using the ASP.NET MVC framework use a “Front Controller” pattern that processes Web application requests through a single controller. When you build a traditional ASP.NET Web Forms application, there is a one-to-one correspondence between a URL and a page.  When building an ASP.NET MVC application, in contrast, there is no correspondence between the URL that you type into your browser’s address bar and the files that you find in your application. In an ASP.NET MVC application, a URL corresponds to a controller action instead of a page on disk.  An ASP.NET MVC application is application logic centric, whereas an ASP.NET Web Forms application is content-centric.

After reading about the differences between page controllers and front controllers, I began to understand some of the excitement surrounding the ASP.NET MVC framework.  It just makes sense to have a centralized point to handle/process requests made to your web application.  It’s kind of like national defense.  It makes sense for the federal government (front controller) to be in control of our nation’s military, instead trying to defend our nation using de-centralized state militias (page controllers).  I’m not sure that’s the best analogy, but it works for me.

Confident in my understanding of the various nuances of MVC implementation, I decided it was time to wade a bit further into the ASP.NET MVC framework (up to my ankles at least).  I found that Scott Hanselman’s video (, Creating with Microsoft ASP.NET Model View Controller (MVC) and corresponding walkthrough tutorial ( to be a great starting point.  The sections on unit testing and support for mobile devices were especially intriguing.

I’m about half way through the walkthrough sample code (it is 196 pages long).  At this point, I’d like to leave you with a few casual observations/opinions:

Happy programming!

Leave a reply

Error getting theme layout