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!