Why(s) & How(s) of Asp.Net MVC Part 1

Background

MVC is the new buzz in development word, everyone is talking and developing with mvc. Knowing how to use Asp.Net MVC is easy, google can give you hundreds of good resources that shows how to configure and write codes. But from my point of view its always better to start from asking why before asking how. Moreover MVC is not alone it wraps around lots of other concepts like db first model first, code first, razor, TDD and so on and on. 
 
Each concept itself is a giant and if you google, will find lots of good resources on them. Starting from this post I am planning a series of articles explaining each of the above concepts or more and slowly move forward to implementation applying these concepts explaining benefits/drawbacks of using those. So plan is to take small steps to reach to the ends. In this first post will discuss benefits, applicability of MVC and life cycle of Asp.Net MVC.  

Why MVC

"Splits user interface interaction into three distinct roles. - Martin Fowler" was the core motivation of MVC. Initially MVC was born as the outcome of the battle of application logic vs user interface. Now abovious question is whats is this all about? Idea is to keep a good separation between the presentation of a program (which is UI) and the rest of the functionality. A separation lets you address on each aspect of the layer separately—and one complicated thing at a time. It also lets specialized people to work on the separate pieces codes. In effort to make both of distinguished an approach/pattern was needed and this approach is the most highlighted part of Model View Controller (MVC). Separation of view from rest of the application logic open a door to change the view logic in future. May be afterwards client asking for more extractive UI or more UX support or worse a complete makeover. If view logic is tightly coupled with business logic's it will be difficult to made the change. 
 
The MVC pattern was first implemented as part of the Smalltalk class library. It was originally used as an architectural pattern for creating graphical user interfaces (GUIs). Later when adopted in the web application the meaning and applicability changed radically. The motivation behind MVC is re-usability and separation of concern. All other benefits is stand on this two building blocks.

MVC Candidates

This has been a huge confusion whether to use MVC or not. But I believe there is not straight answer, it all depends on the application type, resource and time you have to implement and most importantly how much control we need on the application. So bottom line is we must consider carefully whether to implement a web application by using either the Asp.Net MVC framework or the Asp.Net web forms model. MVC has a lot of things to offer, but there are a few areas that we should consider before made the selection.  

MVC suitable for web applications that are supported by large teams of engineers and UX designers who need a high degree of control over the application behavior. If working small teams of engineers and UX designers who want to take advantage of the large number of components available for rapid application development then MVC is may not be a good choice. You should not use Asp.Net MVC if you rely on 3rd party vendor controls for of the UI. MVC leverage the power of object-oriented programming by interfaces, classes and other OOP principles.  If some one is not well-versed with these object-oriented concepts, then the framework might not be comfortable for that person. But if you want to use automated testing, plug-gable architecture, full control over rendered HTML and rich UI support then MVC (in our case Asp.Net MVC) is the best choice.

Asp.NET MVC

The ASP.NET MVC Framework is Microsoft's effort to create an ASP.NET programming environment warped around the MVC pattern. Like the official site says "ASP.NET MVC is a framework for building scalable, standards-based web applications using well-established design patterns and the power of ASP.NET and the .NET Framework.", Asp.net MVC is sitting on top of .NET framework and utilizes the core functionality of asp.net. And it defiantly does not mean web forms are now extinct or too old to use. In my opinion Asp.net MVC is a better way to doing stuffs that we are used to do with web forms. 
 
Now the question is how difficult is to adopt this new framework for developers who are used to with RAD(Rapid Application Development) style? and the answer is its very easy. How? though we are using MVC we are still using visual studio and we are still utilizing asp.net framework, isn't that cool? Yes server controls are not available , but think about how clean the markup would be if there is no server control and as the model/view are all separate testing is lot easier. In the context of our very own ASP.NET web applications, the model, view, and controller participants can be explained as:

• View: This is the HTML markup in ASPX pages. This is rendered in the presentation tier (the browser).
• Controller: This refers to a simple class controller that decide which model needs to be shown respect to which view.
• Model: This a layer who deals with data, which may be processed by the business layer.

 

Page controller pattern, which is the default architecture in the ASP.NET web forms has some limitations.Each page in application has a separate page controller so there could potentially be a lot of code in the code-behind files and lots of maintenance effort. Second issue is testing the application, especially the GUI and the code-behind classes is very difficult, and we cant use test automation tools. Unlike web form which use Page controller pattern, MVC is based on a front controller design, where a centralized controller decides which view to render. And as model, view and controller are all separate so automated testing has never been easier as today with Asp.Net MVC. 

   

Benefits 

Before we come to conclusion whether to use MVC or not lets look couple of benefits of using MVC:

1. Distribute development effort to some extent, so that implementation changes in one part of the Web application do not require changes to another. The engineers responsible for business logic and engineers responsible for flow of control, and Web-page designers can work independently.
2. Easily prototyping is possible. You might do as follows, for example: Create a prototype Web application that accesses several workstation-based programs. Change the application in response to user feedback. Implement the production-level programs on the same or other platforms.
3. You can more easily migrate legacy programs, because the view is separate from the model and the control and can be tailored to platform and user category.
4. You can maintain an environment that comprises different technologies across different locations.
5. The MVC design has an organizational structure that better supports scalability (building bigger applications) and ease of modification and maintenance (due to the cleaner separation of tasks)
6. It does not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application.
7. It provides better support for test-driven development (TDD).
8. It uses a Front Controller pattern that processes Web application requests through a single controller. Thus can design custom routing infrastructure

 

And if we consider web forms as an alternate, lets see what web forms has to offer,

1. It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web Forms-based application provides dozens of events that are supported in hundreds of server controls.
2. It uses a Page Controller pattern that adds functionality to individual pages. For more information, see Page Controller.
3. It uses view state on server-based forms, which can make managing state information easier.
4. It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.
5. In general, it is less complex for application development, because the components are tightly integrated and if we consider LOC then require less code than the MVC.

   

Asp.net MVC Lifecycle

To Understand the MVC request execution Process, we have to start from the very beginning which is IIS. Lets look at it from an IIS perspective now. As Asp.NET MVC is sitting on top of asp.net framework, so from the user request intercept by HTTP.sys to worker process processes the request stays the same as as asp.net web application. Though ASP.NET is executed in different ways in different versions of IIS, but thats discussion is out of context for now. We will concentrate the part where the HTTP request enters the the MVC Framework. 

 
 
Asp.Net request processing can be described in 4 simple steps:

1. Step 1 – Routing : This first step once an ASP.NET application first starts.The UrlRoutingModule intercepts every request. To let MVC routing handler to process requests, configure the routing table during application start-up is required. While configuring MVC with default template, a default routing configuration is provided in global.asax file.
2. Step 2 – MvcHandler : The MvcHandler creates a controller, passes the controller a ControllerContext, and executes the controller.
3. Step 3 – Controller : The MVC controller factory locates and creates the controller in CreateController. The controller determines which controller method to execute, builds a list of parameters, and executes the method. The ControllerContext is passed to the Execute() method on the controller class.
4. Step 4 – Action : Controller methods end with a call to either the RenderView() or RedirectToAction() method. The RenderView() method is responsible for rendering a view (a page) to the browser. The Controller.RenderView() method delegates its work to a particular ViewEngine.

In Short the steps are, 
Request -->Routing --> MvcHandler -->Controller --> Action 

 

The process described above is default behavior, but asp.net MVC allow fine tune the process according to need, even you can improve performance by using specialized controller like asynchronous controller. As of now we covered with basics of MVC asp.net , hope I didn't missed out any basic concepts. In next post we will take a deep dive into Asp.Net MVC describing how to utilize mvc built-in features comparing to web forms. 

One important tip is when an ASP.NET MVC Web application runs in IIS 7.0, no file name extension is needed but in IIS 6.0 you should map the .mvc file name extension to the ASP.NET ISAPI DLL.

Design Patterns in MVC 

Even though MVC is design pattern itself, the entire MVC framework contains some design patterns itself. Below is a list of design parrens used in MVC (or Asp.Net MVC) regardless the platforms. Detaild description of these patterns in MVC are out of the scope of this post, I am sure you can google and could know much more about them.   

Front Controller	Consolidates all request handling by channeling requests through a central controller.
Strategy	The View-Controller relationship, The way conroller hookup view at runtime.
Factory Method	Specify the default controller class for a view
Decorator	In the context of MVC, decorator could fit into your views.
Observer	One Model, Multiples views ( observers/subscribers ), and the publisher manages the communication
Mediator	Several different Models, Several views, and the mediator manages the communications between them.

Source collected from codeproject.com