Behind the scenes of www.ope.ag: Asp.Net MVC
I am a big fan of the Asp.Net MVC framework. Before creating this web site I had already done a few web sites with it and one larger customer project. And for me, there is not really any going back to the old way of Asp.Net Web Forms (Web Forms is the "normal" <form runat="server /> type of Asp.Net).
But what is really different in Asp.Net MVC in comparison to Asp.Net Web Forms? I am assuming that pretty much everyone that reads this knows what MVC is on the high level so I am not repeating it here. If you don't, go to the web site or Google. But in this post I am concentrating to the main differences that I have experienced in practical work.
Issues with Web Forms
One of the main design goals Microsoft had when developing the Asp.Net Web Forms was to enable people who were used to developing Windows UI - basically the Visual Basic developers - to develop also to the web. The idea was that because html and CSS styles had already been developing quite far, it should be possible to create WYSIWYG editors that could be used to create the layout of the pages drag-and-drop and functionality could be programmed using an event model much the same way as in Windows Forms (e.g. by handling a button click or text change event). This was supposed to hide the complexity and the inherent "strangeness" of the web apps: statelessness, html rendering, browser differences, meta programming, server vs. client code etc.
Microsoft was probably doing all this a bit before its time: the web and the browsers were still quite bad in implementing the standards (yes, Internet Explorer, but also the others), the standards were immature and things like AJAX were just emerging. So the end result had a lot of problems:
- The event model was complex and not intuitive
- The view state that was designed to hide the statelessness of the http protocol often grew very big
- There was no proper control of html that would be rendered
- The model encouraged mixing UI logic and business logic together making "spaghetti code".
Now don't get me wrong: even if I thing the Web Forms had a lot of problems in its design, I think ASP.NET was a huge improvement over the old COM based ASP. Just the change from script to type safe "real" programming - to .Net - had a tremendous effect in security, robustness, ability to refactor, reusability and I believe also in productivity. So overall it was a very good thing!
But the problem is there was two ways of doing Asp.Net: the one that was shown in the examples and then the other that was used when developing any serious size enterprise application: Any self-respecting architect would always make his own framework defining which events should be used, how much code should be in code behind, how to create controls, how to use view state etc. And that framework was usually quite different than what MSDN and other resources were showing in their Asp.Net how-to-sections. The frameworks often borrowed from Java and in many places the abstractions provided by Asp.Net were more hindrance that helpful.
MVC to Rescue
Asp.Net MVC is the second attempt. It will not replace the Asp.Net Web Forms completely. Web Forms will also in the future be the choice for quick-and-dirty little apps. Further, the Web Forms also has the performance for large systems and with proper guidance you can do good architectures with it. So if you already have a big legacy, it makes no sense to start converting. But Asp.Net MVC is really the choice - in new apps - for serious enterprise level applications.
The advantages of MVC include:
- Total control over html - on the other side, as you have control, that also means the developers really need to know html and CSS - you cannot rely on the framework handling it for you.
- From ground-up design to separate concerns: View, Model and Controller: It is not spaghetti and meatballs all together, but very carefully separated.
- Easy Unit Testing and the possibility for Test Driven Development (TDD)
- The same model that is mainstream in Java web apps - so if you have developer that come from that world they will feel at home.
Asp.Net MVC was just released March 17th 2009. But it is really much more mature than the date would make you assume. This is because it was developed as an open source project since end of 2007 and people have had the right to use it in production ever since. So there really are quite a few sites that have been running in production for a long time already and the chances that you run into a bug are quite remote. MVC is in the "System.Web.Mvc" namespace so assumedly it will be built in the next version of .Net framework - now you need to download the dll's. MVC and Web Forms work quite well together so you can have both technologies on the same site.
As I said, www.ope.ag is made with Asp.Mvc. What it means is:
- URL's are nice - see this page for example: you do not see the fact that it is coming from Blog.aspx with parameter "id=AspNetMvc"
- I can do full unit testing (Well you guessed it, I did not do any testing for this site, but for a customer app that they just released, I did a very extensive unit testing).
- The html is XHTML 1.0 Strict and validation passes the W3C HTML Validator
- The site is fully formatted with CSS level 2, which passes the W3C CSS Validator
- Everything is simple, architecturally solid and technically beautiful - just the way I like it.
To summarize, my recommendation is that if you have the people who know their HTML and CSS and if you develop large systems, I would make the switch to Asp.Net MVC in new projects. If you say "no" to either of these points or if you have significant legacy, then I would stick to Web Forms.
If you want to take Asp.Net MVC to use in your organization, I am happy to come to help you with that. It could shorten the learning curve a bit if someone is explaining the things from experience instead of everyone just reading a book. Please contact me if you are interested.
Last updated by Olli Perttilä on 3.6.2009