The ASP.NET (Webforms) proposition holds firm in the light of ASP.NET MVC – its strengths are for large corporate development teams working on internally facing LOB applications. ASP.NET MVC on the other hand has an entirely different value proposition and enables teams to work in an entirely different way. Although ASP.NET MVC is intended as a retort to the success of Ruby on Rails, it actually delivers something else – a web platform that finally follows some of the design patterns that the Java Community have been using for the past decade.
ASP.NET Webforms is a white elephant in the web world (but that’s not to say it isn’t a powerful elephant!) – there isn’t another web platform that looks anything like it, which is not surprising as its main goal was to create an abstraction over the web that would allow developers to build web applications as simply as they build Windows applications. In 2009 this abstraction is bringing little benefit to development teams; developers creating desktop experiences are now using WPF, developers creating rich experiences for the web are now using Silverlight, and Microsoft made the right move by reusing the core technologies used and the programming model of WPF. The end result is that ASP.NET WebForms seems slightly outmoded and has a series of fundamental architectural decisions that adds huge amounts of friction to the development process.
ASP.NET MVC on the other hand is a breath of fresh air on the Microsoft Platform. Built by a team of people who are recent recruits to Microsoft, who have years of real-world industry knowledge of delivering web applications using ASP.NET WebForms and know all of the platforms strengths as well as pitfalls and short comings and want to create an alternative that doesn’t make the same mistakes. From my perspective delivering a retail ecommerce site using ASP.NET MVC, combined with the power and features of IIS7, has had an entirely different feeling from delivering one using ASP.NET WebForms – it feels like I’m swimming with the current rather than against it.
Here are the four reasons why it works so well:
It was almost impossible to test ASP.NET Webforms – all parts of the platform were too tightly coupled to be able to write unit tests and from a UI Automation perspective, it was neigh on impossible too as you had no control over the HTML Mark-up, fortunately MVC has been designed from the start with testability in mind. We used BDD as our testing approach on the project and it worked very well indeed, see James Broome’s blog posts on the subject for more information. The result of using BDD is that we’ve written more tests that any other project I’ve been on and because of that the quality of the code we’re producing is getting higher and higher. We’re 10 sprints in (10 x 2 weeks = 20 weeks total build time) and our bug count is in the low 20s (and most of these are style / validation issues).
Because we have absolute control over the HTML Mark-up, we can finally successfully use UI Automation Tools (in our case Selenium) to take much of the regression testing burden off our QA resource. We also use code generation to create multiple test runs using our real product data and use Selenium’s Grid feature to run these tests in Virtual Servers on various different browsers. This means that we can adequately run the project with only 1 QA which in turn reduces the overall cost of developing the solution while keeping quality high.
Separation of Concerns:
Whereas ASP.NET WebForms allowed developers to easily get into a architectural muddle by easily allowing business logic to be written in the wrong place (generally resulting in a “Big Ball of Mud Architecture”) MVC goes some way to creating a “Pit of Quality” that encourages developers to design their applications well, separating presentation logic, from business logic and giving the ability to remove low value, repetitive plumbing tasks. The end result is that MVC applications are far leaner than traditional ASP.NET WebForms applications. This separation also allows far easier unit testing. As James points out in his blog post, the separation of concerns doesn’t just affect the architecture and testability, it also allows the different disciplines within the team (C# Developer, CSS Developer) to separate their own concerns and work very efficiently without treading on each other’s toes, this has massive positive implications for speed of delivery.
Each concern is not only well separated but most constituent parts of the framework are replaceable. The ViewEngine (responsible for rendering the HTML) is probably one of the best examples. On our project we’ve opted to use the Spark View Engine rather than the default WebForms one – as the Spark Engine gives you much finer grain control over your mark up and also offers a much simpler / more elegant templating approach. The outcome of this is that our front end developers are much happier, more productive and fully empowered as they are finally masters of their domain. The other outcome is that the quality of the HTML the produce is far higher, and there are fewer cross browser issues caused by embedded mark-up / styles that plagued ASP.NET Server Controls in the past.
ASP.NET MVC is released under a MS-PL Open Source license – which is truly ground breaking for Microsoft. This one brave move has many achievements, but the greatest is fostering a real community around this platform. It has also allowed the community to “fill in the gaps” and add features and functionality that the core Microsoft Development team could not add in the timeframe they had. The MVCContrib project on CodePlex is a prime example of that – the community has taken the MVC framework and added a huge amount of value. Another example is the Sharp Architecture project – its vision is to create a best practice architectural framework, leveraging the ASP.NET MVC framework with NHibernate and a whole manner of other Open Source libraries.
The Benefit of using Open Source:
The value of these Open Source frameworks and tools is as follows: normally when a project is planned, budget defines the amount of effort that can be allocated. That effort is generally expended in three ways, delivering commodity, delivering core functionality and delivering innovation. What actually happen is that scope enlarges, which increases core functionality and commodity and pushes innovation out of scope for the capacity available. Frameworks like Sharp Architecture allow you to reduce the commodity in your project, and the effort that would be expended on commodity can instead be used for core functionality and innovation:
Could it have been better?
One major criticism to the ASP.NET MVC approach – it really feels like Microsoft has played catch up with Ruby on Rails, rather than learning from its mistakes and leap frogging to the next generation web platform (for example creating a framework like Open Rasta or one based on the Presenter First Design Pattern, which solved many of the problems inherent in the MVC Design Pattern and is also geared towards enabling TDD and Agile). The same end result could have been met by supporting the MonoRail project to deliver a MVC web framework and then spending effort on a vNext web platform.