The ASP.NET (Webforms) proposition holds firm in the light of ASP.NET MVC– its strengths are for big corporate development teams working on inside dealing with LOB applications. ASP.NET MVC on the other hand has a completely different value proposition and makes it possible for teams to work in a totally various means. 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 a few of the design patterns that the Java Community have been making use of for the past decade.
ASP.NET Webforms is a white elephant in the web world (but that’s not to say it isn’t really a powerful elephant!)– there isn’t another web platform that looks anything like it, which is not unexpected as its major goal was to create an abstraction over the web that would enable developers to develop web applications as merely as they build Windows applications. In 2009 this abstraction is bringing little benefit to development teams; developers creating desktop experiences are now utilizing WPF, developers creating rich experiences for the web are now utilizing Silverlight, and Microsoft made the right move by reusing the core technologies used and the programming model of WPF. Completion outcome 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 providing web applications using ASP.NET WebForms and know all of the platforms strengths as well as pitfalls and short comings and wish to produce an option that does not make the very same errors. From my perspective providing a retail ecommerce website utilizing ASP.NET MVC, combined with the power and functions of IIS7, has had a totally various feeling from providing 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 snugly 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 undoubtedly, see James Broome’s blog posts on the subject for more details. 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 many of these are style / recognition problems).
Since we have outright control over the HTML Mark-up, we can finally successfully use UI Automation Tools (in our case Selenium) to take much of the regression screening concern off our QA resource. We likewise make use of code generation to create several 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 minimizes 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 composed in the wrong place (typically resulting in a “Big Ball of Mud Architecture”) MVC goes some method 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 best is fostering an actual community around this platform. It has likewise allowed the neighborhood to “fill in the gaps” and add functions and functionality that the core Microsoft Development group could not add in the timeframe they had. The MVCContrib project on CodePlex is a prime example of that– the community has actually taken the MVC framework and added a huge amount of value. Another example is the Sharp Architecture project– its vision is to develop a finest practice architectural framework, leveraging the ASP.NET MVC framework with NHibernate and an entire way 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 prepared, budget specifies the amount of effort that can be allocated. That effort is typically used up in three ways, providing commodity, delivering core functionality and providing innovation. What actually happen is that scope enlarges, which enhances core performance and commodity and pushes innovation from scope for the capability readily available. Structures like Sharp Architecture enable you to reduce the product in your project, and the effort that would be used up on product 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 capture up with Ruby on Rails, rather than learning from its mistakes and leap frogging to the next generation web platform (for example producing a framework like Open Rasta or one based on the Presenter First Design Pattern, which addressed many of the problems inherent in the MVC Design Pattern and is also tailored 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 investing effort on a vNext web platform.
GeoViz has a history of serving enterprises to move to the next level of operational excellence focusing people, processes, infrastructure, and technology. We deliver, complex software development projects, Team Augmentations(co-sourcing), Business Intelligence, Retails Management, CRM, & Internet Technology solutions. GeoViz serves client inside North America specifically USA and Canada. We have physically served clients in the cities of Seattle, Toronto, Buffalo, Ottawa, Monreal, Hamilton, London, Kitchener, Windsor, Detroit. Feel free to contact us or Drop us a note for any help or assistance.
Drop Us A Note
[gravityform id=”2″ name=”Drop us a Note” title=”false” description=”false” ajax=”true”]