June 29, 2011 Leave a comment
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.
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 http://www.asp.net/mvc/mvc3. It’s a great resource and jumping off point for anyone interested in using MVC3.