MVC/ NHibernate vs WebForms/ Nettiers

Not so long ago my boss asked me to write a report to analyse the use of an MVC/NHibernate stack in a comparison to a Webforms/Nettiers stack. This is a version of the report I wrote to propose that we adopt MVC/NHibernate as standard, across the team, in future developments. I made an attempt at impartiality but failed miserabley (it’s hard to be impartial when I am clearly partial!)

I thought I’d share the contents of this report for more general perusal. The report is my take on why I feel that MVC/NHibernate/SharpArchictecture is a “better” platform for devlopment than good ol’ webforms. The report is aimed at developments tailored towards humanities/academic research projects but with a little tailoring could be relevant more widely. There are likely to be errors or misinterpretations in my analysis so any thoughts/ corrections/ different opinions would be ace.

1. Overview

MVC and Web Forms are the two development frameworks offered by Microsoft. Both share the core ASP.NET platform features including authentication, authorization, configuration, compilation and deployment. Both are developed using any of the core languages such as C#. Both are officially Microsoft supported and developed frameworks.

This report compares using MVC and NHibernate to Web Forms and Nettiers. Firstly it compares the web frameworks and then goes on to look at the data access strategies.

2. Framework Comparison

2.1.1. Benefits of MVC

ASP.MVC was written in response to criticisms of Web Forms in relation to other development platforms. Whilst Web Forms gives developers a Rapid Application Development framework and was written to ‘mimic’ the development methods used in Win Forms, it made it difficult to implement certain practices implemented in other platforms and seen as fundamental to good development.

MVC allows automated unit and integration tests to be written. This has a number of distinct advantages.

1)     Greatly reduces the need for manual testing; the upfront cost of creating unit tests is paid back downstream by significantly reducing the amount of manual testing.

2)     Can be run throughout the development; this is invaluable as it allows the developer to be sure they aren’t introducing breaking changes to the code base.

3)     Gives the developer the confidence to implement changes to the code base as tests will show any bugs.

4)     Leads to a much more rigorous code base as the code has been testing numerous times throughout the development rather than that afforded by sporadic manual testing.

5)     Each test is a FUNCTIONAL requirement encapsulated in code. If there is a requirement that only users with role X can perform activity Y, the test is evidence that this requirement is being met. This becomes invaluable should a developer return to a code base after a period of time as the requirements are directly viewable by running the tests.

A developer can write as little or as much test code based upon the requirements of the project. If a project is exposed to changes in specification then having tests in place significantly speeds up the implementation of changes. For small lower impact developments, automated testing could be scaled back to cover mainly Create/ Update and Delete scenarios rather than Read scenarios.

Writing tests is an art in its own right and one that a developer becomes better at over time. Without writing any test code an experienced developer could create a project using MVC or Web Forms in a similar time. Writing tests would add perhaps 20% to development time, but reduce any time for system testing considerably.

Having tests in place also considerably reduces the time taken to implement changes and if a change is significant may actually allow that change to take place where it would otherwise be seen as either too risky or too time consuming. to principles of good software design

ASP.MVC follows certain well trodden principles of designing good and maintainable software, such as:

  • “Don’t Repeat Yourself (DRY)
  • “Separation of Concerns” (SoC)

Separation of concerns (not mixing UI logic with underlying behaviour) is a fundamental principle that exists to help developers deal with complexity. Mixing different responsibilities within the same object or files (like putting most of your logic in code behind files such as handling edit, cancel and edit post back events) invites maintenance problems and makes that code difficult to change and difficult to read. MVC prescribes where certain types of objects should be written making the resulting code base much cleaner and easier to follow. is prescriptive

Because MVC follows good software design principles it is prescriptive about where certain types of code should be developed. This is useful in a team environment in that it standardises project structures much more than in Web Forms. Once developers are familiar with an MVC project structure it becomes obvious where to look for certain types of code. This will make it easier to work on other developer’s code; a) because of the prescription and b) because running the unit tests will ensure that additional developers aren’t breaking existing functionality. It also helps developer make decisions about where certain types of code should be developed and how code should be separated to allow for easier maintenance. The prescriptive nature an MVC project has also proved useful by allowing the developers in this team to talk about issues and problems they face without having to know the detailed implementation of the project. enables easy integration with JavaScript frameworks

Since the launch of Google Suggest in 2004 there has been a sea change in client side web development. This change has been about the implementation of AJAX functionality. AJAX (shorthand for Asynchronous JavaScript and XML) is a group of related techniques used on the client side, to create rich interactive and responsive web applications. With AJAX, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behaviour of the existing page. AJAX uses a combination of HTML and CSS to mark up and style information. The DOM is accessed with JavaScript to dynamically display, and to allow the user to interact with, the information presented.

This type of functionality used to be a fairly difficult to programme due to the varying implementation of standards compliance across browsers. This has now become less of an issue a) due to better standards compliance and b) more significantly due to the development of JavaScript frameworks such as JQuery that allow you write code that works on every browser.

The ‘V’ in MVC, stands for ‘View’ and deals only with the front end delivery of HTML and JavaScript. MVC allows the easy integration with JS frameworks such as JQuery and greatly simplifies the creation of rich client side experiences using such frameworks. (Note JQuery now ships as standard with ASP.NET 2010 and Microsoft are now actively and perhaps belatedly contributing to the JQuery code base).

This simplified integration makes it easier to develop user experiences that match the performance users expect on a modern web site. This is a subtle point but is one that I believe we shouldn’t ignore. Our clients will increasingly develop implicit expectations about how they interact with websites based on their use of the wider internet. There are now very few commercial sites that don’t implement AJAX functionality and the slick responsive interface that it affords. Not looking at developing rich front ends, will increasingly make our output compare disfavour-ably with our clients expectations. of the web is changing (fast)

Morgan Stanley predicts that more people will access the web using mobile devices than using fixed internet / desktop by the middle of 2013 (i.e. within 2 1/2 years).


What’s this got to do with MVC? I believe that MVC is a better platform to deliver content to a variety of devices due to its easier implementation of JS libraries and the ease with which it allows the developer to control the contents of the HTTP response (explained in detail below).

1)     Easier implementation of AJAX – a 3G connection on a mobile device doesn’t currently have bandwidth comparable with broadband. AJAX greatly improves the performance of pages over slower connections as you only return the required data (which is formatted by the browser) rather than the data and the entire page.

2)     MVC gives the developer much greater control over the data returned from a request. This is best seen with actual code examples but within two lines of code a developer can return an entire page (with Master Page etc), JSON (JavaScript Object Notation) which is the data format of choice in AJAX requests, XML or any other format required.

Code sample:

//Try doing this in webforms

If (IsJson)


return this.JSON(model);


Else if (IsXml)


return new XMLResult(model);




return View(model)l;


This level of control is much more difficult to achieve using Web Forms. Having tight control over what is returned in the HTTP response simplifies development of content for a range of devices such as for traditional browsers or Smart phone apps, or for applications that sit within other platforms such as SharePoint. uses RESTFul URL’s

MVC gives the developer full control over the URL. With WebForms the URL matches the underlying file structure of the code. With MVC you have what’s known as a ‘Route Registrar’ which is a file that matches URL’s to the resources that will deal with the request.

There are two distinct advantages of having full control over the URL:

i)      If a project has a requirement for human readable URL’s or search engine optimisation then URL control is a big advantage. Consider the following:  (i.e. Retrieve user with name alex.hardman)

as opposed to

www.mywebapplication/users/getuser.aspx (name passed in session) or www.mywebapplication/users/getuser.aspx?username =alex.hardman

The first URL (via MVC) is more human readable and search engine friendly (e.g. all things equal would be ranked higher by all the main search engines).

ii)     The second advantage with having full control over url’s relates to the current drive in Digital Humanities research for data preservation. Without going into too much detail one aspect of data preservation involves the creation of “permanent url’s” and “unique resource identifiers” (uri’s).  The standard use of session variables and view state in web forms means that the same url can refer to a multiple items of data (where query parameters are input via view state). The result is that data accessed in this manor data doesn’t have a unique resource identifier (i.e. a unique address on the web). This means data items can’t be referenced as it doesn’t have a unique address on the web and prevents its inclusion in Linked Data initiatives and other research initiatives requiring a URI.

The combination of URI and the ease at which a system can return computer readable data formats such as XML (see above) puts a developer at an advantage when it comes to best practice in Humanities data curation and preservation techniques. At the recent Oxford ‘Research databases in the humanities – where next?’ workshop there was a strong emphasis upon curating Humanities research data with uri’s, and computer readable data formats. This is something that we could ‘sell’ as distinctly advantageous to our research clients.

2.1.2.    Benefits of Web Forms

ASP.NET Web Forms is the more mature of the two methodologies (from a Microsoft perspective) and is currently the more widely adopted.

In terms of development, there are two main things to consider when comparing Web Forms with MVC:

1)     Web Forms has a larger control toolbox (although how many of these a developer uses in their projects is a discussion point in its own right). As a result, it allows developers to develop without needing to be particularly knowledgeable about HTML, CSS and JavaScript. This is flip side of the ‘MVC gives you greater control over the output’ argument. It does but Web Forms automatically renders much of the raw html such as tables, buttons and input boxes (however an MVC enthusiast would respond to this by pointing out that rendering things like tables, buttons and input boxes isn’t a particularly difficult, nor time consuming process. They would also point out that Web Forms developers render tables and other html nodes for general page layout and that such activity is a core competency of the job).

2)     ASP.NET Web Forms was originally designed to mimic the design methods used in the creation of Win Forms and give the developer a Rapid Application Development tool by shielding the developer from the HTTP response and request architecture.  It is likely that this shielding formed part of Microsoft’s strategy for converting desktop (used to winforms) more easily into Web developers (using the analagous webforms) as web development became the dominant development requirement.

In theory this means that a developer can jump straight in by dragging controls onto a page, handling their events and setting values for background colour and ‘bobs your uncle’ – database driven website. In reality, for all but the simplest sites, significant thought is needed, even with Web Forms, when developing both front and backend code.

Desktop development, however, is stateful whereas the Web is inherently stateless. The Web Forms model essentially abstracted a number of features to provide a simulated stateful model for Web developers (aka View State). Despite being one of the development world’s biggest criticisms in relation to Web Forms, there are times when it is useful to provide the illusion that a web application is aware of what a user has been doing. ‘Wizard’ functionality, where data input is spread over several pages before it is committed, is one such example. This ‘stateful’ illusion is provided out of the box with Web Forms unlike with MVC. However in situations where the illusion of state is required it isn’t a difficult exercise to implement in MVC.

In terms of adopting MVC is it worth noting the following. Just as with learning Web Forms, there is a learning curve to MVC. It has a different response/ request pipeline and different ways of structuring application code (no code behind files for example). There is also a knack of writing code that is testable and getting used to the rigour of writing testable code requires practice. MVC requires that the developer gets a rudimentary understanding some new C# code libraries.  These include Mocking frameworks such as Rhino Mocks (which can be used in testing scenarios), Html helpers (used to render html) and the core MVC libraries that deal with ModelState and Routing. There are also concepts like dependency injection/inversion of control to get familiary with.

3. Data Access Framework Comparison

In the past the IT Research Development team used the Nettiers template and CodeSmith to generate data access code. This generates the data access code and if desired some rudimentary data access controls, one for each table. The code generated is robust and affords the developer standard CRUD queries. The developer can extend the range of queries by including stored procedures that can be called using the data access layer.

Prior to generating the data access there are some minor configuration settings to set up, including the default namespace and the connection string. CodeSmith generates the code replacing any existing code files in that namespace.

In the current IBusiness application, data access is handled by NHibernate. NHibernate is a C# port of the popular Java object relational mapping (ORM) tool Hibernate. Its primary features are to map .NET classes to database tables and to provide data query and retrieval facilities. In terms of data query and retrieval it performs a similar role as Nettiers, affording the developer standard CRUD queries.

You don’t need to generate code with NHibernate as you can use its auto mapping facility straight out of the box. NHibernate is however, much more flexible that Nettiers in that you can fully control how values in tables are associated with properties in C# by creating Mapping files. To use NHibernate with automapping requires only that you provide a connection string and that the C# classes to be mapped inherit from an “Entity” class and have the same names as the table columns.

As well as the standard CRUD, you can write complex queries in a few lines of C# using NHiberate criteria.

NHibernate implements the repository pattern. A repository can be understood as a mechanism for encapsulating the storage, retrieval, and searching of objects. The repositories are implemented via repository interfaces, meaning that the code that uses the repositories it amenable to automated unit testing. The repositories themselves are amenable to automated integration tests if that is applicable to the project.

4 Additional Points

(From My Colleague Andrew Jerrison)
SharpArchitecture adds a lot of extras that make MVC development a lot easier and quicker for an experienced developer, plus it automatically generates a very good initial solution template which speeds up development initially.

I feel that MVC is a much better tool from a software engineering point of view, for all the reasons Alex mentions above. It forces the developer to consider the structure of the data and site in a much more rigorous manner than Webforms. This means another developer can come to a project without any prior knowledge and figure out what it is doing quickly. However for the same reasons those not used to an OO approach might find it difficult to get a good understanding of the framework without first learning proper software engineering techniques, thus increasing their learning curve. Webforms was of course Microsoft’s solution to this by making it easier to get simple sites off the ground – however the Webforms approach would not be considered best practice in software engineering courses at Uni.

Webforms is by its nature a rapid development tool. This means that it is quick to get a few pages off the ground. However larger projects quickly become more muddled and less maintainable, especially when less experienced developers are working on the project. MVC has a longer time to set up initial project, but in more complex projects quickly becomes a lot more productive and manageable than Webforms. I would say that Webforms is probably suitable for small projects of approximately 3 weeks or less in duration, and that will not require much maintenance, whereas MVC is better for bigger projects and those that need constant support.

Unit testing is a double edged sword; it certainly increases initial development time, but can greatly reduce testing time and also the time to make and test any future changes and additional features to the project. It can lead you into a false sense of security though, as it is possible to think that just because a test passes then everything is OK, but of course you have to make sure that the test itself covers all scenarios in the first place (Test Driven Design, i.e. writing tests first rather than guiltily adding tests at the end 😉 – Alex). So it is important not to rely solely on programmed unit tests.

Fluent nHibernate is the most flexible object-relational mapping tool I have used so far in my career.

I think that it is also important to mention that the Javascript library jQuery is important to producing good MVC sites. We don’t really use this directly for Webforms as it is more difficult to latch into the HTML generated by the Webforms controls – and Webforms has its own internal AJAX functionality that developers don’t see (and can’t change). jQuery is a very terse syntax which can be a bit obscure at times (similar to Perl), but despite the initial thought of ‘ugh’ when you see it, it is not hard to learn and it is actually much nicer to use than JavaScript itself.

MVC makes it very easy to write RESTful web services that are part of the same application. In Webforms services are not RESTful and are usually a separate application, making testing and maintenance more difficult and time consuming. RESTful interfaces for services are possibly even more useful for our team’s purposes than for the SEO reasons mentioned above as it makes inter-application communication much simpler and easier to implement.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s