I recently had the opportunity to delve into Microsoft’s ASP.NET MVC3 Framework. Although various versions of the framework have been around for several years now, I haven’t had the chance to explore the intricacies of technology until now.

The framework centers around the age-old Model-View-Controller (MVC) design pattern which, in and of itself, is a fairly simplistic concept. The pattern is designed to enforce a clean and logical separation between your business layer and UI. This segregation is accomplished by keeping data and business logic within the model and all UI logic and components within the view. The controller acts as a middle-man, facilitating the communication between the model and view. It takes input from the view and applies the appropriate actions against the model and then passes the results back to the view.

MVC’s knack for separating business and presentation layers helps ensure that the UI is totally disposable. You don’t have to worry about losing some important business rule that somehow slipped its way into the UI layer of your application.

The design pattern also promotes parallel development. For instance, you can stud out a model and a back-end developer can work on hydrating that model with data. In the meantime a UI developer can work on the front-end against the same preliminary model, hopefully meeting in the middle with a finished product.

The clean separation can also simplify application maintenance and enhancement. Changes in one component of the pattern are isolated to that component itself which opens itself up to easier unit testing.

The ASP.NET MVC3 framework provides the developer who has chosen to create an application using the MVC pattern, a quick and intuitive means to a finished product. It’s important to note that if you choose to use the framework, you are committed to work within the confines of the MVC pattern. There is not much wiggle room for coding outside of the pattern and in reality shouldn’t be. However, once you’ve decided to take the plunge and use the framework, you’ll find that it is fairly easy to stick to the MVC paradigm and, in most cases, harder to go astray.

The framework is designed to lean more toward using convention rather than configuration. As a result, your application will have clean and user-interpretable URLs. For instance, let’s take the following URL: http://helloMVC/foo/bar and see how the framework would interpret this request.  In this example, helloMVC is just the application name, foo is the controller and bar is the name of the action method within the foo controller that would perform any interactions, if any, against the model. By convention, you would also have a view named bar. The framework inherently knows to display bar view when the bar action method is called. This is all accomplished by a routing table that is setup in your Global.asax.cs. In the example above we are using the default route which the framework automatically generates when a new project is created. However, you have the option to create your own URL route patterns to fit your needs.

A major difference between MVC3 and traditional web form programming is the absence of code behind files associated with your web pages and controls. In MVC3, any presentation logic that is required is coded in-line within the html blocks that make up your view. So you don’t have to hop back and forth between an aspx and aspx.cs or plow through JavaScript to control the behavior of a given element. You’re presentation logic is wrapped around the element itself. This is made possible by MVC3 use of view engines. View engines are precompiled modules that implement a certain coding template and there are a multitude of them available. Most, if not all, are open source. And which one you choose is totally up to you and your particular coding style. Some view engines are very terse while others are more robust in their syntax. MVC3 ships with a view engine called Razor and it’s the view engine I’m most familiar with. Razor syntax has a strong resemblance to traditional html so most developers will find it very easy to pick up and run with.

In addition to in-line presentation logic, the view engine also allows the developer to interact with the model data passed from the controller. This functionality becomes particularly useful when coupling the framework with ESRI’s JavaScript API. Model data can be accessed directly within a given JavaScript function to be displayed on the map. And conversely, data can easily be captured from user input on the map and be passed back to the controller to update the model.

I found the MVC3 framework as whole fairly easy to use and implement. I see it more suited for new development. However, it would be difficult to try and incorporate the framework in an existing application because to you really have to commit to the MVC design pattern in order to use it. There isn’t anything you can do with this framework that you can’t accomplish using traditional web forms. But MVC seems to be picking up some steam over the past couple of years. The design pattern itself popped up a few times during this year’s ESRI Dev summit. So it may be a good technology to be aware of and keep your eye on.  If you’re interested in learning more or trying out the framework yourself, you can check out It’s a great resource and jumping off point for anyone interested in using MVC3.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: