Microsoft ASP.net MVC Framework, Overlooked and Underrated

Let’s start with those things that we have come to like about Web Forms: server-side controls, stateful pages (viewstate), postbacks, control-independent events, page lifecycles, data binding, and (although independent to the framework) the standard URL mapping. Now let’s take all of these things and throw them in the developer graveyard right next to Visual Basic and strongly-typed datasets. The MVC framework implements a completely separate development paradigm that renders these concepts nearly useless. We shouldn’t be pessimistic though. We’ll first point out the basics of the MVC framework.

The origins of the Model-View-Controller paradigm date back to a paper published in 1979. Just for some perspective, President Reagan had not even received the Republican nomination, I was not born yet, and an ice age may have just occurred. Back on subject, the paper calls for a design pattern in which the Model (M) represents a functionless stateof an application, the Controller (C) changes the state (modifies the model), and the View (V) visually paints the model in its current state. In the context of our interest, Microsoft has implemented this paradigm in the form of web pages. It is unfortunate that ASP.net MVC has not garnered significant attention and is often overlooked as an easier solution.

In short, the positives of MVC lie in its simplicity and performance. In terms of load time, MVC will beat a comparable Web Forms page every time. Additionally, MVC naturally promotes separation of code and logic. Moreover, the simplicity of MVC implicitly makes it more predictable than its Web Forms counterpart. “My view state is gone. My Event isn’t firing. My data binding is happening out of order. I don’t know where to place or perform this in the page lifecycle. I have to validate my query strings” … these are all headaches that just aren’t part of building MVC applications. Removing the page lifecycle, view state, and server-side controls and replacing them with models (or view-models) have replaced all of these concepts. Lastly, the concept of a model is very friendly for holding database entities. You could argue for hours during team lunch about where database information should be connected in a web form. With MVC, team lunch time is better spent knowing that database entities will have to lie in the model in order for the view to display them.

As with any framework or language, the negatives are always there. The most prominent headache with MVC is the idea of routes. Routes convert the URL you are requesting the appropriate view. This map is constructed in one centralized area and may become extremely complex. An incorrect route can render not just a single page inoperable, but an entire web site inoperable if the mistake is prominent enough. Additionally, the large increase in the use of render tags may make some developers believe this is a kickback to classic ASP. In short, yes, MVC does use render tags to generate forms and what used to be server-side controls, but, hey, “What’s old is new,” right? Finally, the most dreaded part of MVC *queue the gong* is the inclusion of JQuery. Any AJAX calls or complex controls are typically handled by the JQuery framework.

In closing, MVC could be made into the “go to” solution instead of the fringe solution. A faster, extensible, and logical framework could make your team of developers more productive and develop web sites that are not only more stable, but also perform better than a Web Forms alternative. Consider it!