by Jan Blomquist 10. February 2010 09:54


MVC (Model View Controller) is an architectural pattern and in many ways the preferred approach for layering your application. ASP.NET MVC is Microsoft's solution to a set of common challenges that face web developers today. Some of these problems are: -

ASP.NET MVC "forces" the developer to model their application according to their MVC architecture and brings greater control and granularity over markup. Because of this, ASP.NET Ajax (or jQuery for that matter) becomes easier to use since you no longer need to deal with for example autogenerated IDs (ie: ctl101_panelContainer_GridView1) which can be hard to use in client-side ajax applications.

Throwing the baby out with the bath water

Another alleged "benefit" of ASP.NET MVC is that the WebForms model is thrown out, so concepts like ViewState, Postbacks and fully templated event driven server controls doesn't exist anymore. This can be a good thing for an html/css/javascript ninja who wants the pedal to the metal and don't like too many abstractions, however I would argue that MVC on top of the WebForms model is far more superior and in this blog we are going to outline the structure of such an application.

An example of a successful ASP.NET MVC implementation today is StackOverflow -one of the most frequently visited websites for professional developers online today. The development of this project is a small group of developers (3?) who work day to day on the project and have deep intrinsic knowledge of it's inner workings. 

ASP.NET MVC might be the right choice for you depending on your requirements, but creating ANY ASP.NET application today without utilizing some form of MVC seems outrageous IMHO. I would put forth the following postulate derived from this claim:

A well designed ASP.NET WebForms application is an MVC application

Let's take a closer look at how you would assemble such an MVC application using the WebForms model. Don't forget the following regarding design patterns: "A a design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations" - Wikipedia


We've created a small application that utilizes the MVC pattern on top of the WebForms model today. Currently it's published at one of our build servers.

When you open the sample you can click the (Click here to get the details]) button to expand various code listings and some code explainations. Let's walk through the application structure together. It's a simple list of Tasks that can be filtered by date and contact person. Since the whole idea is to separate the business code/logic from each UI/View I've created a few models and multiple views. The model is basically just a contract (interface) which defines the operations which the controller needs in order to function. Each View must implement the contract so the controller can do it's work. You have full freedom to architect your models as you find suitable and I would recommend you to favor composition over inheritance .


Here's the code for the IActivityModel

Codebehind (C#/.cs)

   1:  namespace Gaia.WebWidgets.Samples.Combinations.WebApps.MVC.Models
   2:  {
   3:      /// <summary>
   4:      /// This is the model that "glues" together the filter and results and is the
   5:      /// main input to the Controller which then works against this model
   6:      /// </summary>
   7:      public interface IActivityModel
   8:      {
   9:          IActivityFilter Filter { get;}
  10:          IActivityList ViewResults { get;} 
  11:      }
  12:  }

 In order to reuse the Filter I've created it as a separate model. Then I went ahead and created a model which will be used to viewed the results based on the filter. This is the IActivityList model which can be seen here:

Codebehind (C#/.cs)

   1:  namespace Gaia.WebWidgets.Samples.Combinations.WebApps.MVC.Models
   2:  {
   3:      using System.Collections.Generic;
   4:      using Utilities;
   6:      /// <summary>
   7:      /// Model that allows binding of results to a View
   8:      /// </summary>
   9:      public interface IActivityList
  10:      {
  11:          void View(IEnumerable<CalendarItem> data);
  12:      }
  13:  }

As you can see, the only operation currently needed is the View method which takes an IEnumerable in order to bind the data. By using such a low common denominator, we can bind to almost anything for presentation, even a custom scheduler component if one were to require such functionality.


The sample has defined 3 views (Repeater, GridView and Listbox) + 1 Mock View used in UnitTests. The codebehind file for the GridView View can be seen here:

Codebehind (C#/.cs)

   1:  namespace Gaia.WebWidgets.Samples.Combinations.WebApps.MVC.Views
   2:  {
   3:      using System.Web.UI;
   4:      using System.Collections.Generic;
   5:      using Models;
   6:      using Utilities;
   8:      public partial class ActivityListGridView : UserControl, IActivityList
   9:      {
  10:          void IActivityList.View(IEnumerable<CalendarItem> data)
  11:          {
  12:              zGrid.DataSource = data;
  13:              zGrid.DataBind();
  14:          }
  16:      }
  17:  }

In this case we created a UserControl, but it could also have been a server control or an arbitrary class also. It just doesn't matter when modelling after the MVC pattern.

Some have argued that you loose control over markup with the WebForms model and that is true when using powerful components like (GridView, Scheduler, Window, TabControl, etc), but it doesn't have to. Here's a code excerpt from the RepeaterView and as you can see this will give you full control over rendered markup:

Markup (ASPX/.aspx)

   1:  <%@ Control 
   2:      Language="C#" 
   3:      AutoEventWireup="true" 
   4:      CodeBehind="ActivityListRepeater.ascx.cs" 
   5:      Inherits="Gaia.WebWidgets.Samples.Combinations.WebApps.MVC.Views.ActivityListRepeater" %>
   7:  <gaia:Panel ID="w" runat="server">
   8:      <ul style="border: 1px solid #999; margin: 5px 5px 5px 0px;">
   9:          <asp:Repeater ID="zView" runat="server">
  10:              <ItemTemplate>           
  11:                     <gaia:Label ID="f" runat="server"><li></gaia:Label>
  12:                     <gaia:Label ID="dt" runat="server" Text='<%# Eval("ActivityDate", "{0:ddd dd. MMM}")%>' />
  13:                     <gaia:Label ID="p" Font-Bold="true" runat="server" Text=' <%# Eval("ContactPerson")%>' />
  14:                     <gaia:Label ID="t" ForeColor="red" runat="server" Text='<%# Eval("ActivityName")%>' />
  15:                     <gaia:Label ID="l" runat="server" /></li>
  16:              </ItemTemplate>
  17:          </asp:Repeater>
  18:      </ul>
  19:  </gaia:Panel>

And really? Are abstractions like Window, Scheduler, Grid bad? I would'n want to develop without my reusable server controls!

The C in MVC - Controllers

Ok - we have defined the model and seen the code for some views. Let's examine the Controller and see how that works.

Codebehind (C#/.cs)

   1:  namespace Gaia.WebWidgets.Samples.Combinations.WebApps.MVC.Controllers
   2:  {
   3:      using System;
   4:      using System.Collections.Generic;
   5:      using Utilities;
   6:      using Data;
   7:      using Models;
   9:      /// <summary>
  10:      /// This is the Controller in the MVC pattern and it acts as the "hub" and is responsible for
  11:      /// working on the models and implementing business rules, DAL communication, etc
  12:      /// </summary>
  13:      public class ActivityController : ControllerBase
  14:      {
  15:          private readonly IActivityModel _activityModel;
  17:          public ActivityController(IActivityModel activityModel)
  18:          {
  19:              _activityModel = activityModel;
  20:          }
  22:          public override void Initialize()
  23:          {
  24:              _activityModel.Filter.BindPersons(ActivityDataLayer.GetContacts());
  25:              _activityModel.Filter.When = DateTime.Now.Date;
  27:              ViewChanged();
  28:          }
  30:          IEnumerable<CalendarItem> GetItems()
  31:          {
  32:              return ActivityDataLayer.GetByDateAndPerson(_activityModel.Filter.When, _activityModel.Filter.SelectedPerson);
  33:          }
  35:          public override void ViewChanged()
  36:          {
  37:              _activityModel.ViewResults.View(GetItems());
  38:          }
  40:      }
  41:  }

Another model From the code you can see that we take a model as input parameter to the constructor. This model will be the View itself. In the initialize method we set default values for the DateTime filter and populate the list of available ContactPersons from which the UI can select a person. The IActivityFilter also denotes the SelectedPerson so we should have sufficient information to perform a Filter operation and retrieve data.

Notice the call to the View method on the model where the data is passed in. This takes place in the ViewChanged() operation which can be invoked from the UI too. For example in the SelectedIndexChanged event of the dropdownlist. Ok, so now you have seen the three layers in the MVC architecture. The benefits we have seen so far is

  • Disconnected UI from business logic.
  • UI/Client could easily have been something else (Mobile, WinForms, etc)
  • Removed code from the UI where it might introduce "spaghetti code"
  • Stricter adherence to contract lessens error likeliness

Unit Testing

Ok, but how would you go about and test this stuff? We could have tested this in multiple ways, but the easiest is probably to create mock objects that represent the Views and then pass these MockModels as input parameters to the Controller. Here's a few "dummy" examples of some unit tests. I've just faked the unit test framework and you can swap this out with your favorite unit testing framework. 

Codebehind (C#/.cs)

   1:  namespace Gaia.WebWidgets.Samples.Combinations.WebApps.MVC.Tests
   2:  {
   3:      using System;
   4:      using Controllers;
   5:      using Data;
   7:      /// <summary>
   8:      /// This is just a "dummy" test-suite to demonstrate that it's easy to write
   9:      /// TDD - Test Driven Development against an MVC application
  10:      /// </summary>
  11:      public class ActivityTests
  12:      {
  13:          public void Test_ActivityController_TestInitialize()
  14:          {
  15:              ActivityModelMock mock = new ActivityModelMock();
  16:              new ActivityController(mock).Initialize();
  18:              bool dateInitialized = mock.Filter.When == DateTime.Now.Date;
  19:              DummyAssert.IsTrue(dateInitialized);
  20:          }
  22:          public void Test_ActivityController_TestFilter()
  23:          {
  24:              ActivityModelMock mock = new ActivityModelMock();
  25:              new ActivityController(mock).Initialize();
  27:              ActivityListMock view = mock.ViewResults as ActivityListMock;
  29:              bool sameData = ActivityDataLayer.GetByDateAndPerson(
  30:                  mock.Filter.When, mock.Filter.SelectedPerson).Count== view.CalendarItems.Count;
  31:              DummyAssert.IsTrue(sameData, "Different data based on same filter");
  32:          }
  34:          public void Test_ActivityController_TestMockObject()
  35:          {
  36:              ActivityModelMock mock = new ActivityModelMock();
  37:              new ActivityController(mock).Initialize();
  39:              ActivityListMock view = mock.ViewResults as ActivityListMock;
  40:              DummyAssert.IsTrue(view != null, "Unable to get test implementation");
  41:          }
  43:      }
  44:  }

Suddenly we've created a robust architecture based on the principles of MVC. Also we've taken advantage of all the good things that come for free in Gaia Ajax and we've built on top of the powerful WebForms model on ASP.NET. And we've made our code highly testable and reusable.

Routing / Dynamic Loading

What more could there be? Well, since you're asking we could have implemented dynamic loading of views (routing?) based on some scheme (url, page, configuration, etc) and in fact this sample automatically loads the available Views dynamically and populates the DropDownList with all the Views that implement the model that we are looking for. This functionality is implemented on the page level and allows you to switch out UI/View on-the-fly. Just click here and  try it out for yourself.

Other ASP.NET MVC drawbacks

An author behind one of the ASP.NET MVC books (Jeff Putz) points out some of the ASP.NET MVC drawbacks on his blog

  1. It also lacks the kind of UX encapsulation that we get with Webforms. For example, I have a template based image gallery control that I've used time and time again. The markup that appears in each cell of the table can be anything I want, and I can tell it to leave a "hole" for a template containing an advertisement. All I do is drop it on a Webform and fill in the templates and it automagically works. This kind of reuse isn't in the strictest sense possible in MVC if you're adhering to the design pattern.
  2. The magic of having a simulated stateful form is also gone, with no postback mechanism. The entire event model is thrown out.
  3. Views feel a little like spaghetti code from old ASP (the scripting platform that used the tragic VBscript)
  4. And the biggest concern I have is that developers won't be thinking about security the way they should. It's already possible in Webforms (or any other platform) to put together an HTTP request with the right information to simulate a legitimate user action and do naughty things when the right preventative code is not in place, but it's even easier in MVC. A URL like "/cats/kill/42" is probably intended to execute cat.Lives-- and it's easy to guess. A lot more care has to be taken to validate data and enforce security.

At the moment I don't see any reason to abandon the WebForms model in favor of ASP.NET MVC, generally because we've had MVC for a long time already, but more specifically for the reasons outlined above and in particular because of simulated Windows Forms development experience brought by the WebForms model. I can respect that many developers don't see this from my point of view if they are using jquery/ ajax and similar client-side technologies. The MVC architecture on top of the WebForms model becomes truly aparent with the right tooling and proper abstractions -like Gaia Ajax. The same would go for related techologies like (Google Web Toolkit)


The following quote from Jeff Atwoods blog pretty much summarizes my feelings about the ASP.NET MVC stuff:

"As we work with ASP.NET MVC on Stack Overflow, I find myself violently thrust back into the bad old days of tag soup that I remember from my tenure as a classic ASP developer in the late 90's. If you're not careful bordering on manically fastidious in constructing your Views, you'll end up with a giant mish-mash of HTML, Javascript, and server-side code. Classic tag soup; difficult to read, difficult to maintain."

If you want to comment on the blog, please use our forums at

Where's the Right Way to Ajax?

by Stian Solberg 20. April 2009 10:59

Dino Esposito has written an article on DotNetSlackers with an oveview of different Ajax Web Architectures. The article covers how Gaia Ajax fits into a "Active Server Pages" pattern, and why Gaia is a solid architecture for your next web application.

Gaia Ajax is an Ajax toolbox for ASP.NET and Mono. The library is dual licensed, where you can use the GPL license for building open source projects, and for your proprietary projects you can obtain a commercial license.

Read the complete article on DotNetSlackers

Principles of UI architecture for libraries

by Jan Blomquist 20. October 2008 12:40

In this article we shall discuss some of the core tenets when creating UI frameworks/libraries and how these principles guides us in the development of Gaia. Gaia is an Ajax library for the ASP.NET platform. It takes a philosophically radical different approach than it's platform counterparts, including Microsoft's own ASP.NET Ajax framework.

Many of the assertions here applies just as much to general software development as it does to framework development. It is however necessary with a stronger emphasis on a number of principles since you are now in the sphere of building software for other programmers and not general purpose end user applications. This leads us to one of the first postulates. The developer is the customer.

# The Developer Is The Customer

This gives us a little edge, because we are ourselves in fact developers. We know perfectly well how we want the product to be like. Unfortunately this statement does not always hold true. If it did, then all software libraries would be perfect which they are not. Another pitfall is not keeping your hands dirty, gradually moving away from day to day development work into abstract philosophical reflections in your ivory tower. Suddenly your product doesn't solve the developers itches anymore and it cannot survive.

The derived conclusion is to keep a close customer feedback loop with a focus on customer driven development. Including transparent tracking facilities, daily build system with unit tests and early/often releases. You must listen to the [voice of the customer].

This first postulate is mostly connected with the art of quality, but is deemed so important that leaving it out would make this work look poorer. Quality in your craft extends beyond the product itself and into the whole organization. The product is often just a manifestation of the quality.

Now that we know who the customer is, what can we do for him? This gives us the second postulate. More...

Suite, best of breed or in-house development

by Jan Blomquist 22. August 2008 19:49

In this blog I want to write about the pros and cons when choosing between suite, best of breed or in-house development when setting up the infrastructure of a developer shop. I will reason why we chose best of breed and the argumentation that lead to this conclusion.This blog will contain most references an examples to products on the Microsoft .NET platform, but the content was written to be read by anyone including non-developers. 

So what are the differences between the three alternatives. 

 Re-inventing the wheel


  • A Suite can be thought of as a collection of applications from a specific vendor. It doesn't have to be a commercial alternative and DotNetNuke is one example of a suite where all the major components are delivered in a single box (wiki, forum, blogs, cms, etc).
  • Best of breed are standalone applications that work isolated and doesn't rely on being part of different ecosystems. For these systems to be efficient they should provide a mechanism to be integrated with other systems. An example of a good best-of-breed system is YetAnotherForum which only focuses on delivering a good forum solution
  • In-House Development is building the stuff you need yourself. Skilled developers can rapidly build the desired functionality on an on-going basis and usually you build what you need as you go. 

"Personally I've experience with all three of the approaches and there are clear benefits and downsides to all of them. " More...