gopalk

ASP.NET MVC in production

gopalk — Tue, 17 Mar 2009 19:07:46 GMT

Is ASP.NET MVC ready for production use?

ASP.NET MVC Beta version was the first one to come with an explicit go-live licence. We went live with our first ASP.NET MVC website in December, based on ASP.NET MVC Beta and the results have so far been very impressive. The beta was of high-quality and very stable during development. With the release candidates its only got better and hopefully the release version isn’t too far away. In my opinion releasing the source code and keep the community involved via Codeplex, forums and blogs has played no small part in keeping the quality of this framework high.

The website has performed very well since then under some pretty intense load. So in our case, ASP.NET MVC is certainly proved itself ready for production use. Here I have tried to compile a list of ASP.NET MVC tips, advantages and pain points based on my experience with ASP.NET MVC.

Tips for MVC

Before using ASP.NET MVC think about your UI requirements. Are you counting on a third party UI library? If you are thinking of using third party controls that use postback or viewstate then ASP.NET MVC may not be for you! Although bear in mind that it is possible to have ASP.NET webforms page within an ASP.NET MVC web application.
Decide on client side and server side validation strategy early : ASP.NET MVC doesn’t have validation built in, it only provides support for it via ModelState. You’ll need to decide on a server side validation framework e.g. Enterprise validation block, data annotations, Castle Validator etc. You’ll also need to decide on a client side validation framework e.g. jQuery validate plugin.
Understand controller lifecycle and ActionFilters: Understanding the lifecycle of the controllers and about ActionFilters will help you create controllers and presentation logic correctly and with minimal code. It will also help you move the cross cutting concerns like authentication, authorization etc out of your presentation logic. See my previous post for this.
Have base class hierarchy for controller and views to provide required functionality: Don’t derive from the Controller class directly for your controllers, but create a custom base controller where you can provide functionality common across all controllers. I have found this useful for Views and Model classes as well.
Move routes out of code into configuration: Having to recompile every time you add a new route is a pain, move the routes out into a web.config or an external file. This is easy to do as ‘defaults’ parameter on RouteCollectionExtensions.MapRoute no longer expects anonymous types, an object of type RouteValueDictionary can be passed in.
You can use URL rewrite module along with routing: It is possible to use regex url rewrite module along with MVC. This will kick in before MVC receives the request and MVC will receive the modified request. This is useful for cases where you want to use regular expressions as as regex routes are not currently supported by MvcRouteHandler.
Keep Views as dumb as possible: Remember Views are supposed to be so dumb as to require minimal testing, so keep it that way.
Keep controller as lean as possible: Having too much code in the controller is a sign that you are perhaps missing a Service facade class.
Anything involving viewstate or postback will not work within a ASP.NET MVC page: Support for ASP.NET webforms controls is limited e.g. ViewState and Postbacks aren’t supported. Test any controls you plan to use early on with ASP.NET MVC. There are other options like MVP if you absolutely need a server control not supported by MVC but want the testability benefits of ASP.NET MVC. ASP.NET webforms page can be used within an ASP.NET MVC web application.
RouteData is very useful – If you want to get hold of any route related data associated with the current request. It is accessible within Controller and Views and it can be used to retrieve current action name, controller name, route name etc.

Why MVC?:

Separation of concerns – separation of concerns in dividing the UI (View) from presentation logic (Controller). The domain model is separated from the above two as well, but that’s a common practice even if you are using ASP.NET MVC webforms.
Testability –The controller receives user input, acts on user input, supplies ViewData to the View and presents the View to the user. This clear input and output model means that controllers are very testable.
Extensible – Extensibility is a big feature of ASP.NET MVC. Some of the many extensibility hooks within ASP.NET MVC are:
- RouteHandler – The default ASP.NET MVC route handler is MvcRouteHandler. A custom route handler can be used if you want customized route handling logic for a particular route.
- ControllerFactory – Create your own controller factory if you want to instantiate your controller using an IoC container, or choose one from here http://www.codeplex.com/mvccontrib
- ViewEngines – Views are normally located and processed by WebForms ViewEngine infrastructure, but there are custom ViewEngines available like nVelocity etc.
Control over HTML – ASP.NET MVC allows fine grained control over the HTML generated, great if you don’t like all auto generated HTML related to viewstate and server controls in ASP.NET webforms.
REST – ASP.NET MVC provides SEO friendly and RESTful URL’s
MVCContrib – Last but not the least, a great resource, provides lots of community contributed content for MVC.

That said ASP.NET MVC is still very new and naturally has a few areas that need a bit of work:

Grouping of controllers – ASP.NET MVC doesn’t provide a way to group controllers into ‘areas’, which is quite important for a large project. There are a few solutions from the ASP.NET MVC community for this, including one here: http://blog.codeville.net/2008/11/05/app-areas-in-aspnet-mvc-take-2/
View and ViewData issues– ViewData container object is not strongly typed, this results in a lot of defensive coding within the View in reading values from this container. This also causes any possible type mismatches not to come to light until runtime. Using strongly typed views can help this issue to an extent, so can using Generics base ViewData setters and getters like this:

       SetViewData<T>(“keyname”, T data);
    

End to end validation framework – An end-to-end validation framework is missing. This at the moment means defining validation rules both at the server side (e.g. via Enterprise validation block) and client side (e.g. via jQuery) separately. The new xVal framework aims to address this issue: http://www.codeplex.com/xval
Repeater controls – Simple rendering controls with templating capability such as Repeaters etc are sorely missed in ASP.NET MVC. An possible solution here: http://haacked.com/archive/2008/05/03/code-based-repeater-for-asp.net-mvc.aspx
Self contained controls – At the moment user controls in ASP.NET MVC are not fully encapsulated i.e. the code required to load the ViewData for the control must be called from every controller that presents the control. Subcontrollers aim to address this: http://www.codeplex.com/mvccontrib
IIS6 install a bit messy – Installing MVC on IIS6 involves setting wildcard mapping and needs to carefully planned and tested early on. Make sure to disable wildcard mapping from any sub folder that only contain only static files for performance reasons. More info here: http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Regex support for the routes – At the moment routing system doesn’t support regex based routing. A possible solution here : http://blog.sb2.fr/post/2009/01/03/Regular-Expression-MapRoute-With-ASPNET-MVC.aspx
Asynchronous processing – While there is no out of the box support for asynchronous processing within ASP.NET MVC, here is a possible solution: http://blog.codeville.net/2008/04/05/improve-scalability-in-aspnet-mvc-using-asynchronous-requests/
Dynamic loading of routing – Routes are right now added from within code and there is no support for storing routes within an external data store, although such a functionality can be easily added. Many possible solutions available for this including this: http://mnour.blogspot.com/2008/11/mvc-routing-using-custom-configuration.html

Given the ASP.NET MVC framework is relatively new, these shortcomings are quite understandable. Furthermore most of the above issues also have community contributed solutions and workaround, so none of them pose a major impediment to the use of ASP.NET MVC. The framework should also improve and add features that are currently missing with newer releases. It remains to be seen how the vast server controls market for ASP.NET webforms responds to ASP.NET MVC. I think that this will be quite important for the widespread adoption of ASP.NET MVC. Overall, in my opinion, ASP.NET MVC provides us with a new reliable, testable and extensible framework for web development which is well worth trying out.

Del.icio.us Digg It Share on Facebook Stumble It!

How does ASP.NET MVC work – Part 2

gopalk — Wed, 11 Feb 2009 07:41:21 GMT

In the last post we saw how an ASP.NET MVC request gets routed through to the MVC framework through the ASP.NET framework. We also saw that the MvcHandler class is the HttpHandler responsible for servicing an ASP.NET MVC-request. A simplistic view of the order in which routing and MVC classes come into play is like this:

UrlRoutingModule -> MvcRoutingHandler -> MvcHandler

So at this stage our request has got an HttpHandler assigned in the form of MvcHandler. Moving ahead in the HttpApplication event processing, the fulfilling of a request takes place when the ProcessRequest method on the MvcHandler gets invoked.

MvcHandler

Within the ProcessRequest method, the original HttpContext is wrapped into an HttpContextWrapper instance. HttpContextWrapper implements an abstract class called HttpContextBase.

Loose coupling: Within an ASP.NET MVC controller, HttpContext is referenced not directly but via this abstract HttpContextBase class. As evident, this enables loose coupling between your controller class and the HttpContextWrapper instance and thus improves testability by allowing you to easily mock your HttpContextBase class when performing unit tests. This loose coupling also extends to other objects like Request (referenced to via HttpRequestBase) and Response (HttpResponseBase). These abstract types are defined within a separate assembly System.Web.Abstractions.dll. This opens up the possibility of using them outside the MVC framework!

Compare this to a traditional WebForms Page, where the Page class references the HttpContext via a direct reference, and the HttpContext object is also sealed. So it’s difficult to mock HttpContext for testing purposes, thus making a WebForm page difficult to test. This is one clear advantage of ASP.NET MVC over traditional WebForms.

At this point we have two classes that carry information about the request. These are RouteData and HttpContextWrapper (Packaged up into RequestContext and assigned to MvcHandler earlier during the PostResolveRequest stage of the UrlRoutingModule). RouteData is a dictionary object containing key value pairs related to the matching route. The information RouteData will contain will typically be controller name, action name, route name, default parameter etc matching the current request. These are extracted from the parameters passed into the RouteCollection.RegisterRoute calls made in Global.asax:
```
   1: routes.MapRoute(
```
```
   2:     "Default", // Route name 
```
```
   3:     "{controller}/{action}/{id}", // URL with parameters 
```
```
   4:     new { controller = "Home", action = "Index", id = 1 } // Parameter defaults
```
```
   5: );
```

RouteData can also be used from within the Controller (via ControllerContext) and View (via ViewContext) to get the current route name, action name, controller name etc. Thanks to RouteData dictionary, at this point MVC knows the name of the controller and the action to be invoked.

ControllerFactory (DefaultControllerFactory)

Further in the ProcessRequest method, a controller must be located to fulfil the current request. To do this, a controller factory is acquired first. By default in ASP.NET MVC this is an instance of DefaultControllerFactory. In typical ASP.NET MVC fashion there is an extensibility point here too.

A controller factory must implement IControllerFactory interface and a custom controller factory can be registered to override the DefaultControllerFactory in Global.asax.

   1: protected void Application_Start() {
   2:     ControllerBuilder.Current.SetControllerFactory(<Your controller factory>);
   3:     ...           
   4: }
One of the reasons you would want to register a custom controller factory is, if you want your controllers to be instantiated by an IoC (Inversion of Control) container and injected with dependencies like Loggers etc dynamically. There is some more information on how to create a custom controller factory for ASP.NET MVC here: http://www.pnpguidance.net/Post/SetDefaultControllerFactoryIControllerFactoryASPNETMVCFramework.aspx

The MVCContrib project on Codeplex makes available controller factory classes with support for various popular IoC frameworks like StructureMap, Castle Windsor, Unity Framework and Spring.NET: http://www.codeplex.com/MVCContrib

IController (Controller)

Once an instance of the controller is retrieved from the controller factory, Initialize method is called on the controller. This is an important part of the controller lifecycle which provides access to the request and is a good place to initialize properties on the controller.

IActionInvoker (ControllerActionInvoker)

Next the Execute method is invoked on the instance of Controller class and RequestContext is passed in as an argument. This sets off the controller lifecycle. An object of type IActionInvoker rather than the controller itself controls the order in which various methods on the controller and filters are executed.
```
   1: bool IActionInvoker.InvokeAction(ControllerContext controllerContext, string actionName)
```

(ControllerContext is composed of the RequestContext and Controller instance.)

Notice the separation of concerns and yet another point for extension. A custom implementation of IActionInvoker can be assigned to the Controller if we want our action invoker to do things a bit differently. The default implementation of IActionInvoker is ControllerActionInvoker class, and does quite a bit behind the scenes as we’ll see below:

First parameter values are obtained for the parameters on the action method. This is done by a ModelBinder. A ModelBinder is responsible for converting the data in request (i.e. form parameters, querystring parameters etc) into parameter values that an action method accepts. Of course, this is yet another extensibility point in the framework where a custom ModelBinder can be assigned to an action method via the use of attributes (Note the influence of AOP (aspect oriented programming) in the framework). The default ModelBinder is used if a custom ModelBinder is not specified. More information here on creating custom ModelBinders: http://www.singingeels.com/Articles/Model_Binders_in_ASPNET_MVC.aspx

Now the various filters are executed. Simply put, filters are interceptor methods that can execute before and after the action method execution. They allow you to separate cross cutting concerns or non-action-specific code from the code in the action method (Notice the nice use of AOP). There are different types of filters:

Authorization Filter – IAuthorizationFilter interface
Action Filter – IActionFilter interface
Result Filter – IResultFilter interface
Exception Filter – IExceptionFilter interface

Authorization Filter is the first set of filters to be executed. Processing can be halted within this stage by cancelling the action. This can be done by setting the cancel property on AuthorizationContext to true.In the code below, the further processing of the action is cancelled, the RedirectResult is executed which should result in a redirect to Login action. An authorization attribute can be implemented by deriving from AuthorizeAttribute (which implements IAuthorizationFilter) and applying the attribute to an action method. The Controller class itself implements IAuthorizationFilter, so the easiest way to implement an Authorization Filter is to override the OnAuthorization method inside your controller class.
```
   1: public override void OnAuthorization(AuthorizationContext filterContext)
```
```
   2: {
```
```
   3:     filterContext.Cancel = true;
```
```
   4:     filterContext.Result = new RedirectResult("/Home/Login");
```
```
   5: }
```

Action Filter – OnActionExecuting: If the processing isn’t cancelled above, then the OnActionExecuting method on the action filter collection is executed. Again as with Authorization Filter, Controller itself implements IActionFilter interface, so an OnActionExecuting method is available to be overridden within the controller class. This is another point where execution of any further action filters and the action itself can be cancelled by setting the result property to an ActionResult of your choice.
Action method itself is invoked with the parameters supplied by the model binder.
Action Filter – OnActionExecuted: After the execution of the action method, OnActionExecuted method on the action filter collection (including the OnActionExecuted method on the controller) is executed. In this method you can get information on any exceptions that were thrown during the action method execution via ActionExecutedContext.Exception. Here you have a chance to handle the exceptions and stop further propagation of the exception by using the ActionExecutedContext.ExceptionHandled property.
Exception Filter – OnException: An exception filter must implement IExceptionFilter interface. As with other types of filters, it can be applied as an attribute. The controller implements IExceptionFilter interface and provides access to its functionality via OnException method that can be overridden within the controller class. This is called if an exception is thrown anywhere during action or result execution. An exception thrown in the Action can be handled in OnActionExecuted to stop it from being propagated up to this stage. Similarly as will be explained later on, an exception thrown during result execution can be handled inside a ResultFilter OnResultExecuted stage to stop it from getting here. ExceptionFilter offers you the final chance to handle exceptions before the exception is thrown up to Global.asax. HandleErrorAttribute is an exception filter provided out of the box with the framework to help with exception handling within the controller.
Result Filter - OnResultExecuting: This step occurs before the ActionResult is executed. A result filter must implement IResultFilter interface and the Controller class offers an implementation via the OnResultExecuting and OnResultExecuted methods. The request will only get here if there are no unhandled exceptions in the action method and the OnActionExecuted stage.
ActionResult execution – This is the stage where the ActionResult is executed and the http response determined. ActionResult is just an abstract class and is extended by specific type of action results like ViewResult (for HTML output), JsonResult (For Json output), RedirectResult (an HTTP redirect), ContentResult (for text output) etc. This is another extensibility point, which allows a custom ActionResult implementation. See an example here: http://blog.maartenballiauw.be/post/2008/05/ASPNET-MVC-custom-ActionResult.aspx

IView and IViewEngine

Rendering a view – When the return type from the action is that of a ViewResult there are two interfaces, IView and IViewEngine that get involved. IViewEngine interface defines the contract for locating a view or a partial view. IView defines the contract for rendering the view. By default the framework uses WebFormView and WebFormViewEngine which process .aspx based views. A custom view processing infrastructure can be implemented by creating custom views/view engines. The MVCContrib project on codeplex provides several ViewEngines including those based on XSLT, Brail and nVelocity. Some more information on creating a custom ViewEngine can be found here: http://www.singingeels.com/Articles/Creating_a_Custom_View_Engine_in_ASPNET_MVC.aspx

Result Filter – OnResultExecuted: This is the last step executed within the controller and occurs after the result has been executed and http response produced. If any exceptions are thrown during the result execution, then you’ll have a chance to handle the exception here. If not the exception is bubbled up towards Exception Filters (see Exception Filters - OnException stage).

After this stage the http response would have been produced and the control is transferred back to HttpApplication to carry through the rest of the lifecycle. This concludes our journey through the request processing occurring within the ASP.NET MVC framework.

This follow-up post explained the passage of a request through the ASP.NET MVC framework and describes how the request is processed through the various stages within. Hopefully it gives a good idea of the ASP.NET MVC lifecycle and extensibility points within it.

Del.icio.us Digg It Share on Facebook Stumble It!

How does ASP.NET MVC work?

gopalk — Tue, 20 Jan 2009 06:56:00 GMT

If you’ve looked at the ASP.NET MVC framework, you might have wondered how it fits within the rest of the ASP.NET lifecycle. To understand it though, the ASP.NET request lifecycle needs to be understood first.

What happens when an ASP.NET request is made?

The answer depends on the version of IIS being used. In IIS 5.0 / 6.0, ASP.NET support was accomplished using an isapi extension i.e. aspnet_isapi.dll. In IIS 5.0 / 6.0 there is a distinct handover of the request from IIS to .NET before any managed code can respond to the request. This is achieved by mapping certain extensions like .aspx, .asmx etc to aspnet_isapi.dll extension by using application mapping within IIS manager interface.

But in IIS 7.0 (running in integrated mode) things are different. IIS 7.0 integrates the ASP.NET runtime with the core web server and there is no specific handoff needed from IIS to ASP.NET. Thus for a managed HttpModule to execute, the request doesn’t have to be routed to ASP.NET first. A managed HttpModule can be added via IIS manager itself and can be made to execute for both managed and native requests. Similarly a managed HttpHandler class can be mapped to specific extensions directly via IIS manager (which stores the configuration in applicationHost.config file.) or via the web application’s web.config file.

So what happens when a request gets through to ASP.NET?

1. ApplicationManager and HostingEnvironment classes are created. ApplicationManager class manages Applications and their AppDomain for all the applications on the hosting process. ApplicationManager can be used to do cool things like hosting ASP.NET in your custom process, see here: http://www.west-wind.com/WebLog/posts/4976.aspx . This is also the stage when any necessary compilation of code in App_Code folder occurs.

2. HttpRequest, HttpResponse and HttpContext objects are created and populated. At the end of this stage these objects are usable.

3. Now the current HttpContext is assigned to an instance of HttpApplication (or instance of Global.asax if exists). At the same time any HttpModules (inherited from parent app or defined in web.config) are initialised. The HttpApplication class defines a set of stages/events that get executed one by one and carry the processing forward in distinct steps. Note that the HttpModules that have been initialised will attach themselves to one or more of these lifecycle events defined on HttpApplication instance.

4. HttpApplication lifecycle events fire in succession:

Note that the list of lifecycle events on HttpApplication is extensive and the objective here is not to analyse the entire lifecycle, so I’ll skip the parts that are not directly relevant for this exercise. For an extensive look at HttpApplication lifecycle elements look here:

IIS7: http://msdn.microsoft.com/en-us/library/bb470252.aspx

IIS5/6: http://msdn.microsoft.com/en-us/library/ms178473.aspx

The first relevant event in the HttpApplication lifecycle that we need to look at is MapRequestHandler. Now this step is new in .NET 3.5 but an equivalent step (without the corresponding event) existed before .NET 3.5. It is in this step that an HttpApplication selects an HttpHandler to service the request. Now the selection of HttpHandler will be based on web.config or inherited configuration. The HandlerFactory set in the configuration will be used to acquire an instance of the Handler which is then assigned to the context.

So for example, if a request is for an ‘aspx’ file, in the MapRequestHandler stage, HttpApplication will map ‘.aspx’ request to PageHandlerFactory. GetHandler method is then invoked on PageHandlerFactory which returns an instance of the appropriate Page class (Page is basically an HttpHandler and implements IHttpHandler interface). This is then attached to the Handler property of the context class.

Let’s skip a few more steps and go to the ProcessRequest stage. By now the request (To be precise the HttpContext object encapsulating the request.) already has an HttpHandler assigned to it as seen earlier. The request is now processed here by invoking the ProcessRequest method on the HttpHandler.

Wasn’t this about MVC?

In MVC, there is no concept of a Page as in a traditional webform page, i.e. the web page requested doesn’t exist on the disk as a file. Instead it’s served up by a special method (‘the Action’) on a special class (‘the Controller’). This is quite a dynamic routing arrangement as it needs to respond to varying URL’s. And if you do not want to use a special extension (like .mvc) for these MVC requests, then you can’t really use an HttpHandler entry in web.config/IIS. (There does exist a handler for .mvc in web.config if you want to use .mvc extension for your MVC requests.)

So, how does ASP.NET know how to route requests to MVC? The answer lies in web.config. There is a new http module added to modules collection in ASP.NET MVC projects

This was originally a part of MVC framework but since has been released as a separate assembly. The other part in this routing magic is played by Global.asax RegisterRoutes method.

routes.MapRoute("Default", "{controller}/{action}/{id}",new { controller = "Home", action = "Index", id = "" });

MapRoute is an extension method on RouteCollection class that can be used to define possible routes. In the background this method sets the routes you define to be handled by MvcRouteHandler class.

The UrlRoutingModule attaches itself to PostResolveRequestCache and PostMapRequestHandler events of the HttpApplication instance and overrides the default behaviour of MapRequestHandler stage. UrlRoutingModule does this by searching the RouteCollection for a route matching the request. If it’s found, the associated RouteHandler is retrieved from the RouteCollection. In our case this is an MvcRouteHandler instance. An instance of MvcHandler is retrieved from MvcRouteHandler and assigned as the handler for the current context. Nice thing to note is that RouteCollection is one of the points where the MVC framework can be extended. This can be done by defining a custom RouteHandler corresponding to the routes (instead of the MvcRouteHandler). There is some good information here on how to this.

http://msmvps.com/blogs/luisabreu/archive/2008/07/23/the-mvc-framework-the-mvcroutehandler.aspx

As a side note, also note that UrlRoutingModule will by default ignore any requests that match a file that exists on the disk. Thus if a request for WebForm1.aspx is received and it happens to exist on the disk then route lookup will be skipped for this request. This behaviour can be changed (at your own peril!) by setting routes.RouteExistingFiles = true ;

Now there might be a case where a custom handler needs to be defined within our MVC web application (For integrating third party products/user controls). This may not exist on the disk and will trigger a route table lookup and a 404 if no matching routes are found. To avoid this, RouteCollection can be instructed to ignore this specific path in the following way.

routes.IgnoreRoute("<your route>");

So in this post we saw how a request was routed from IIS through to the MVC framework and along the way, an extensibility point was identified. From here it needs to be routed through to the right action on the right controller class, but that could be the topic of an entirely new post!

Del.icio.us Digg It Share on Facebook Stumble It!