Introduction

At DevConnections Fall and TechEd Europe, Microsoft recently unveiled the ASP.NET MVC Framework. MVC stands for Model-View-Controller and is one of the most popular design patterns for decoupling data access and business logic from data presentation and user interaction. At the time of this writing, the framework is not available yet, not even as a CTP. However, the first CTP is expected to ship in just a few weeks.

In any case, the ASP.NET MVC Framework is definitely worth a look since it addresses aspects of programming that are extremely important for developers and their productivity such as code reusability, testing, and separation of presentation and business logic concerns. At the same time, an early look at the MVC Framework may generate good feedback to Microsoft and help them to deliver a better and richer product in full accordance with the community expectations and needs.

Motivating the Hype on MVC

Most applications, and especially Web applications, have their presentation layer mixed up with some business logic and data access code. As an example, think of a classic ASP.NET page. You define the user interface by composing and configuring server controls until you obtain the desired markup. Next, you use a code-behind class to add some handlers for the various events fired by controls and provide any required glue code. In such pages, more often than not, data access code is interspersed with presentation logic. In ASP.NET 2.0, the introduction of data source controls certainly didn't make this mixture more unlikely. Some data source controls, such as the SqlDataSource control, are a sinful temptation for developers as they see in it the way to go down to SQL queries and stored procedures - the raw data - very quickly. Without beating the bush around, such ASP.NET pages whose code-behind classes contain a mixture of presentation, business and data access code, are quite difficult to maintain. And they are definitely challenging to test appropriately.

User interface facilities (i.e., wizards and tools in Visual Studio) tend to encourage developers to put in the presentation layer more than it should. The presentation layer acts as a catch-all for logic that reasonably belongs to other layers. At the end of the day, you can still have the application working and perform well. Behind the scene, though, you get a too high level of coupling and subsequently high costs of maintenance. What if, in fact, at some point you need to add a new feature or re-implement an existing one? Not having a well designed structure of classes and lacking a clean separation of presentation, business and data layers, most that you can do is cutting and pasting code and run pages over and over again to test results against expectations.

There's not much of reusability too, but quite the reverse I'd say. Code duplication is not unlikely and the need of changing the view for the same data may often result in serious trouble.

Sure, there are architectural design patterns to give you guidance on the best way to design Web applications with cleanly separated layers. However, these patterns require a lot of coding, sometimes repetitive code, which doesn't always sit well with the rush of delivering applications that just work. While the startup costs of implementing recognized patterns manually will certainly pay you off in the context of complex enterprise applications, it seems to be an unnecessary complication in simpler, but still realistic, scenarios.

The classic code-behind model of ASP.NET provides the tools for building great and well-designed applications, but it leaves most of it up to the individual developer or team. As a result, too many applications out there work well, but are not well designed. Over the years, this fact raised the need of a radically different approach to Web programming. The MVC pattern was soon identified as an excellent approach to Web development. MVC ensures a clean separation between the data model and the user interface in such a way that changes to the user interface don't affect data handling. At the same time, the data model and related access code can be refactored without the need of changing the user interface accordingly.

Where Did I See This Already?

Tools like Castle MonoRail have been created to simplify Web development by leveraging the MVC pattern. Where's the difference between MonoRail and ASP.NET? It mostly lies in an extremely simplified form of the code that backs a page up. It's like breaking the code you have in, and reference from, the code-behind class into distinct elements. The controller handles application flow; the model represents the data; the view takes care of presentation. The underlying engine automates some tasks for you (i.e., binding data to form elements) and exposes just plugs for you to connect and customize the engine. As a result, you write less code and have highly specialized components that are easier to test and maintain.

At the same time, MonoRail is not necessarily better than Web Forms and may not be the right choice for just everybody. Because it propounds a different paradigm, it may not be the ideal environment for those who have strong ASP.NET skills and find it difficult (or just not affordable) to convert large applications.

By the way, regardless of the Mono prefix in the name there's no necessary connection between this project and the Mono project aimed at providing the code to run .NET applications on multiple platforms.

Comparing the MVC Framework to Classic ASP.NET

The ASP.NET MVC Framework is essentially the Microsoft's attempt to create an ASP.NET programming environment centered around the MVC pattern. For the time being (nobody can reasonably foresee future evolutions), the MVC Framework should be considered an alternative to Web Forms. To some extent, the MVC Framework and Web Forms have in common more or less what cars and motorcycles share. Both can take you somewhere else, but with different speed, comfort, sense of freedom, size of the trunk.

The MVC Framework doesn't support classic postbacks and viewstate and doesn't consider any URL as the endpoint to a physical server file to parse and compile to a class. In ASP.NET, you have a 1:1 correspondence between a URL and a resource. The only exception to this rule is when you use completely custom HTTP handlers bound to a particular path.

In the MVC Framework, a URL is seen as the mean to address a logical server resource, but not necessarily an ASPX file to parse. So the URLs employed by the pages of an MVC Framework application have a custom format that the application itself mandates. In the end, the MVC Framework employs a centralized HTTP handler that recognizes an application-specific syntax for links. In addition, each addressable resource exposes a well-known set of operations and a uniform interface for executing operations.

Have you ever heard about Representational State Transfer, or REST for short?

Well, REST is an architectural pattern that defines how network resources should be defined and addressed in order to gain shorter response times, clear separation of concerns between the front-end and back-end of a networked system. REST is based on three following principles:

• An application expresses its state and implements its functionality by acting on logical resources
• Each resource is addressed using a specific URL syntax
• All addressable resources feature a contracted set of operations

As you can see, the MVC Framework fulfills it entirely.

So here's an alternate way of looking at the MVC Framework. It is an ASP.NET framework that performs data exchange by using a REST model versus the postback model of classic ASP.NET. Each page is split into two distinct components -controller and view - that operate over the same model of data. This is opposed to the classic code-behind model where no barrier is set that forces you to think in terms of separation of concerns and controllers and views. However, by keeping the code-behind class as thin as possible, and designing the business layer appropriately, a good developer could achieve separation of concerns even without adopting MVC and its overhead. MVC, however, is a model superior to a properly-done code-behind for its inherent support for test-driven development.

The figure below summarizes my perspective of classic ASP.NET and the MVC Framework.

Figure 1: Contrasting ASP.NET and the MVC Framework

While MVC is definitely a key part of the framework, I wouldn't consider it is the most compelling part. REST is a possible alternative to the postback model, whereas MVC is an alternative to code-behind.

Explaining the MVC Framework to ASP.NET Developers

Awaiting for the first binaries to ship in just a few weeks, you can get some demo code for your home perusal from the Scott Hanselman's blog. The Scott Guthrie's blog offers a few insightful posts already and I suggest you monitor it for further news and examples. Here's a list of other interesting posts you might want to read:

• The REST-like Aspect of MVC Framework
• ASP.NET MVC Framework: An early look
• RSS Feed with the new ASP.NET MVC Framework
• MVC, REST, and the Alternative ASP.NET Framework
• ASP.NET MVC framework - ready or not

I wonder what's the quickest and most effective way to explain the MVC Framework to seasoned ASP.NET developers. It's like having a central HTTP handler that captures all requests to resources identified with a new extension. This HTTP handler analyzes the syntax of the URL and maps it to a special server component known as the controller. The controller supports a number of predefined actions. The requested action is somehow codified in the URL according to an application-specific syntax. The central HTTP handler invokes the action on the controller and the controller will process the request up to generating the response in whatever response format you need. The response is generated through a view component.

What here I called the "central HTTP handler" plays the same role that was of the System.Web.UI.Page class in classic ASP.NET. The Page is the handler responsible for any .aspx request and generates the markup using the code-behind class and serves it back using postbacks. In the MVC Framework, this pattern - hard-coded in the ASP.NET runtime and not subject to change until the whole ASP.NET platform is rewritten - is simply implemented using an alternative HTTP handler and an alternative model based on REST and MVC.

Now the one-million question that everybody should try to answer. When and why do I need REST and MVC? Stay tuned, time will tell.

About Dino Esposito

Dino Esposito is one of the world's authorities on Web technology and software architecture. Dino published an array of books, most of which are considered state-of-the-art in their respective areas. His most recent books are “Microsoft ® .NET: Architecting Applications for the Enterprise” and “... This author has published 35 articles on DotNetSlackers. View other articles or the complete profile here.

---

Discussion

Subject	Author	Date
about ASP.NET MVC	Raju Yusuf	10/21/2009 9:18 AM
This article gives description about how to handle ASP.NET MVC Reply | Permanent link
about ASP.NET MVC .+link	Raju Yusuf	10/23/2009 12:27 PM
This article gives description about how to handle ASP.NET MVC postback: http://www.altafkhatri.com/Altaf/ASP_NET_MVC_Postback/Dropdownlist_Example/PostBack Reply | Permanent link
Good article	Randolpho St. John	11/21/2007 10:15 AM
This is a great article, with a good explanation of the differences between ASP.NET and MVC. One of my biggest beefs with ASP is the over-reliance on the post-back, which breaks web standards.  MVC simply cannot come out soon enough.( "Premature optimization is the root of all evil." -- Donald Knuth Reply | Permanent link
Great article!	Granville Barnett	11/21/2007 2:16 PM
I think the MVC framework when released will be adopted very quickly - like said in the previous comment I can't wait for the MVC framework.  Roll on the CTP bits :-) Reply | Permanent link
MVC and webMVC which is not	Uffe Seerup	11/23/2007 7:18 AM
Hi Dino I’m sorry for the long comment, but I feel this has to be said. Anyone who is interested in MVC should read Trygve Reenskaugs original paper (from 1979), the origin of MVC in smalltalk-80: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html It is clear from that paper that webMVC is not at all an implementation of the MVC pattern. The real MVC is a recursive pattern, in which the view is a composite with multiple subviews. Each view element possibly providing its own specialized controller (an editor). The views are stateful and persistent across user interactions. The views both read and update the model. The top controller never updates the model; its task is simply to arrange/create/destroy views as response to user actions, possibly requiring new controllers (editors) from the views. The actual input and consequent updating is handled down the line through these editors. webWVC as it appears in Struts, Rails (and ASP.NET MVC, I'm afraid) is a very different beast: Views are transient, they do not generally read the model (data is handed over from the controller) and they certainly never update the model. Views are merely rendering procedures; they may call upon other rendering procedures, but they are not composites. The webMVC controller is a monolith which must handle all actions originating from the view procedure hierarchy; unless of course actions are diverted to another monolith using a filter. Some ignorant fellow got it wrong and have now successfully hijacked the term. It is a petty, because one of the primary motivations for design patterns was indeed a consistent terminology. Even textbooks now claim that webMVC as it appears in Rails, Struts and their offspring are “smalltalk-80 MVC adapted to the 'net.” But perhaps the biggest difference is in the philosophical origin. MVC was all about putting the user in control. MVC is a pattern which let the user control the application. Sadly, most webMVC implementations are ways to have the application control the user. (I suspect that's why Trygve refers to some variants as "perverted").  This is perhaps best illustrated by e-commerce sites which insist that I review my cart every time I add or remove a product. It is the equivalent of my supermarket cart driving off to the exit lines every time I drop something into it or take something out. Why do they do that? Because either the developer had to implement the cart actions in each and every controller, or redirect to another “cart” controller. Problem is that the cart controller lost the state of the original view. Indeed, it could be argued that the web form model of ASP.NET where template ~ view and codebehind ~ controller is much closer to the original MVC than webMVC, and indeed posseses some of the same qualities such as composability and emphasis on user control. I’m not going to pretend that the current web forms model is without problems. But the problems you mentioned with classic ASP.NET fall in two categories: 1) Separation of the model from presentation logic and 2) Testability. I really don’t see webMVC making 1) any less likely. Indeed, my Rails experience has shown me that very same problems exist in this posterchild for webMVC. The strong emphasis on Active Record leads developers confused about where to implement logic which doesn’t sit well a single AR class, such as a transfer between to accounts. Often they will implement it in the controller. It is the path of least resistance. Same problem. This type of logic should go into a business layer (transient business objects) which sits on top of the data abstraction layer (persistent business objects). I don't know how to guide developers to do this, but it is annoying just the same. As to 2), testability is indeed a problem with ASP.NET webforms. But I’m not so certain that it couldn’t be solved in some other way which did not throw the composability and focus on user control overboard. Another potential problem of webMVC is that it tends to invade the entire site. That may be ok if the site is an application. But if it was just a site, the more loosely coupled model of ASP.NET pages may be preferable. Reply | Permanent link
RE: MVC and webMVC which is not	Murtaza Mustafa	12/1/2007 1:53 PM
quite interesting... Reply | Permanent link
RE: MVC and webMVC which is not	Chad Myers	12/1/2007 6:27 PM
Uffe: most of your arguments boil down to gripes about how dumb people will use good frameworks to do dumb things (like your e-Commerce example of an abuse of webMVC). You sound like a grumpy old smalltalk programmer :) Yes, we ALL know how vastly superior smalltalk was :)  smalltalk is like the Latin of our modern English world. I agree that webMVC is an 'adaptation' of the original MVC, but so what? It's a good model and it's a decent adaptation to a completely different environment (stateful vs. stateless).  Until a good continuations solution is in place for Ruby/Java/.NET, what else can we do?  ViewState? Hah! :) I totally agree with your ActiveRecord point. AR is a HUGE leaky abstraction. It's handy for banging out small, quick applications, but in a large/enterprisey app, forget it. Actually, this point has been hashed ad nauseum in other forums and mailing lists.  I'll be using DDD which is NOT a leaky abstraction and using DI to inject services into controllers to take the specific concerns of persistence and validation OUT of the controller. As far as testability, I just posted about this on my blog a few days ago (www.chadmyers.com/blog) and I'll be writing an article for this site which explores this in more details. Microsoft have added interfaces that wrap the HttpContext, HttpRequest, HttpResponse, HttpSessionState, etc so that there are no opaque dependencies and we can do mocking in our unit tests. Our options for testing are greatly improved here and, indeed, TDD is a reality now. Blog: http://chadmyers.lostechies.com Reply | Permanent link
RE: RE: MVC and webMVC which is not	Uffe Seerup	12/17/2007 5:36 AM
Hi Chad, Lol. In the interest of full disclosure, I've never programmed a single line of smalltalk, although I must admit to an interest in the language. I may be grumpy, yes. I was a C++ developer when I was first hit with design patterns (the trusty old GoF book). As I outlined in my comment webMVC is very, very different from the original smalltalk-80 MVC. I really don't think "adaptation" is an appropriate word. It is two completely different design patterns, in implementation, philosophy and goals. webMVC is not without merit. It has certainly proved effective in Rails. My main issue is that it has completely trashed the good work of the design pattern pioneers by thoroughly confusing the terminology. What is best practice in MVC is now considered a direct violation of wevMVC. Case in point: MVC views should read/update the model. webMVC views should not read the model directly and may not update the model. By calling it webMVC I recognize it as a design pattern, but attempt to disambiguate it from the priginal MVC pattern. They are two completely different patterns. That said, I also see some serious limitations of webMVC. It can be summed up as lack of composability. You could argue that it is due to the nature of the disconnected http protocol, but I don't buy that. I believe that we can do better than webMVC. I see a solution where ViewState is complemented by "UriState" so that the developer can create truly idempotent pages when required. I believe that the solution is a return to the real MVC pattern, introducing URI state and the Builder pattern as model in some cases. The ASP.NET control tree also looks like a good candidate for unit tests. Imagine being able to test for "deltas" of the control tree, i.e. the test framework records the state before actions being applied, compares afterwards and allows the developer to formulate assertions about the changes. ASP.NET webMVC seems to me to be an inferior Rails clone. Inferior because Ruby is much better suited for that particular model. The way RoR communicates from the controller to the view is much more elegant. Everything in ASP.NET webMVC requires (a lot) more code. Reply | Permanent link
RE: RE: RE: MVC and webMVC which is not	Chad Myers	12/17/2007 10:38 AM
@Uffe: > ASP.NET webMVC seems to be me to be an inferior Rails clone This is a correct statement, for the most part. The inelegancy of ASP.NET MVC is due, mostly, to the strict class typing system in C#/VB.NET/etc as compared to the dynamic nature of Ruby.  ASP.NET MVC does have the advantage of some of the 'enterprisey' stuff in ASP.NET (namely the authorization/authentication schemes, caching, super scalable threading/pipelining, asynchronous page execution, etc -- things the Ruby platform is currently incapable of doing. This may be mitigated once IronRuby (Ruby on .NET proper) is released on the .NET DLR. So we have that to look forward to! Blog: http://chadmyers.lostechies.com Reply | Permanent link
It always comes back to Dino	Stephen Bridgett	12/16/2007 11:04 AM
Thanks for a great article Dino, (as usual). Over the last few days, snowed in, I have been trying to get my head around the quickly evolving architectural possibilities of asp.net. LINQ, with all its wonderful magic seems to be a powerful, beautiful but untamed creature. With a few lines of code we get voila, instant data binding. The risk it seems to me, is that of having anonymous types of 'SQL" sprinkled throughout the application landscape. The ease of doing it XBase style is compelling but the profound ease of Linq could easily cause mainstream architecture to slide back to the monolithic code block of days gone by. The MVC, DAL, BLL and UI type patterns could be relegated back to acedemia in the never ending rush to market timelines we developers always face. Your description of the emerging Asp.net MVC has given me hope that all will not be abandoned with the flick of the LINQ switch. Reply | Permanent link
Exploring MVC	Jess Likens	1/19/2008 2:40 AM
I've been tinkering with the ASP.NET MVC framework since the CTP was released.  I'll be posting my discoveries as I go over here. Reply | Permanent link
Was confused.. but now it's clear	Sameer Alibhai	5/1/2008 6:29 PM
I was quite confused about MVC, but your article, even though its PRE-CTP, is very clear and explains the issue well.  I think this would be a good idea to implement in order to force developers into good style. Do you agree? Sameer SharpDeveloper.NET - My .NET / Programming/ Development Blog Reply | Permanent link
What is the difference between MVC and EJ Beans in Java?	Behzad Sedighzadeh	7/29/2008 3:27 PM
Hi, Good article.i did not know anything about MVC in ASP.NET before.Your article  turned light onto to the darkness. BTW, 2 question: 1.What is the difference between EJB and Asp.NET MVC?they look very similar! 2.i develop all my applications with the design guideline of the patterns and practices.It enforcees us to have 3 tier: Data ( Data helper and DALC) business and Presentation ( GUI,UIPB, etc.).Now  i think ms gurus have returned to what they had told us before. Still i think the biggest change is the use of HTTP hjandlers just like what java developers have done so far! Thanks a lot. Reply | Permanent link
thanks	Ali Sedran	11/28/2008 2:15 AM
good article Reply | Permanent link
ASP.NET MVC 1.0 Released	Keith Newman	3/18/2009 5:34 PM
Now that ASP.NET MVC 1.0 has been release, Microsoft has published more about MVC on the MSDN Web site. To view the MCV content, go to http://go.microsoft.com/fwlink/?LinkId=145989. Reply | Permanent link
A Simple Explanation of MVC	Rick O'Shay	4/18/2009 11:50 AM
MVC is one of the most poorly defined patterns and discussions typically involve entirely unrelated concepts.  A Model is a data structure. A controller directs calls to reshape the data model or return a specific view of that data The code managing the controller,  models and view are separate. Even more simply put, the "view" is an abstract representation of a "model" as directed by the "controller" (show me the Norwegian Blue parrot inventory). Web-pages, command-handlers and data access managers fit this pattern nicely, but with MVC we usuallly use a front-controller pattern, so commands get processed by a central controller. In addition to the front-controller, there is almost always a dispatcher and a routing table. The table dictates which page should be loaded, based on the current page, the command that was issued, and the result code. This removes dependencies between pages. Rewiring is easy, dynamic routing is trivial. I'm surprised it took 10 years to get an official release of this technology. In another ten, perhaps we will see a more compelling technology being used ubiquitously in Java circles: Dependency Injection Containers. The benefits provided by that are even more dramatic than MVC. Reply | Permanent link

---

Please login to rate or to leave a comment.