ASP.NET MVC with Webforms

source code can be found here 

It’s now generally admitted in the community that Unit testing and TDD (Test Driven Development) are valuable techniques when it comes to increasing the overall quality of our code. Nevertheless unit testing can be costly especially when you’ve applications with a lot of logic implemented in the UI. Therefore if we want to make our application testable we need to separates the UI from the rest of the application.

Martin Fowler described on his site some patterns that separate and diminish the UI logic to a bare minimum. They are all variants of the classical MVC (Model View Controller) pattern. The MVC split the application in 3 parts: the view handles the display, the controller that responds to user gestures and the model that contains the domain logic. The MVC is the foundation of very popular portal frameworks like Ruby on Rails.

To build web sites applying the MVC pattern with .Net developers can choose among several MVC frameworks like Monorail or the new ASP.NET MVC. In anyway, MVC frameworks like ASP.NET MVC are based on completely different paradigm as the ASP.NET Webforms framework. This means that you have to re-learn to program web apps from scratch. Another setback is that there are no ways to refactor your old ASP.NET applications so that they can fit into the MVC framework. I want to make myself clear, I believe that frameworks like Monorail or the coming System.Web.MVC are the future way of programming web apps in .NET but it demands a considerable amount of effort to learn new frameworks. It’s difficult for someone like me who has invested lots of years in mastering the classical ASP.NET code-behind model to re-learn everything from scratch. In the meantime this should not be an excuse to not make my code more testable.

In this post I will explicit through a simple example how to use the model view controller pattern on top of the code-behind model. We will create a login form with the MVC pattern.

Setup your solution

Create a new solution “Zoo” with 3 projects –>

  • ZooWebsite-> ASP.NET web appplication
  • ZooLibrary -> Class library 
  • ZooTest - Class library
  • Create a reference from ZooWebsite to ZooLibrary

    (ZooWebsite , add reference, project tab select ZooLibrary)

  • On ZooLibrary add a reference to System.Web

ne project


The View

To make our code testable it’s very important to be able to decouple the UI from the ASP.NET code-behind.  Therefore we will create an interface our ASP.NET page should implement.  This View interface will represent the contract the UI as to conform to.  When we will test our controller we will not do this with our actual web page but through a mock object that implements the View interface.    

Add an interface ILoginView on the project ZooLibrary:

   1:  namespace ZooApplication.Library
   2:  {
   3:       public interface ILoginView
   4:      {
   5:          string ErrorMessage { get;set;}
   6:          string EmailAddress { get;set;}
   7:          string Password { get;set;}
   8:          void RedirectFromLoginPage();
   9:          System.Web.UI.WebControls.Button BtnLogin { get;set;}
  10:      }
  11:  }
  • Edit the default aspx page and enter: Welcome you are authenticated!
  • Add the login.aspx to the ZooWebsite project.
  • Edit the source of the login.aspx part -> add two textboxes, a button, and validators:
<%@ Page Language="C#" AutoEventWireup="true" Codebehind="Login.aspx.cs" Inherits="ZooApplication.Website.Login" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="">
<head runat="server">
    <title>Login page</title>
    <form id="form1" runat="server">
                Login form<br />
                <asp:Label ID="LblErrorMsg" runat="server" Text="Invalid login" Visible="false" ></asp:Label><br />
                Email Address:
                <asp:TextBox ID="TxbEmailAddress" runat="server"></asp:TextBox>
                <asp:RequiredFieldValidator ID="RfvEmailAddress" runat="server" ErrorMessage="Enter your email address!"
                <asp:RegularExpressionValidator ID="RevEmailAddress" runat="server" ControlToValidate="TxbEmailAddress"
                    ErrorMessage="Invalid email address!" ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*">
                <asp:TextBox ID="TxbPassword" runat="server"></asp:TextBox>
                <asp:RequiredFieldValidator ID="RfvPassword" runat="server" ErrorMessage="Enter your password!"
                <asp:Button ID="PageBtnLogin" runat="server" Text="Login" />

Because the code-behind is not testable and don’t make part of the SUT (Subject Under Test) we want to diminish the code-behind logic to a bare minimum.   The view responsibility is limited to output  the data coming from our model in a human readable way and to expose user input to the controller.

Therefore we implement our interface through an aspx page that only contains a set of properties that binds data coming from the controller with our web controls. 

Generally we will try to implement all the presentation logic into the controller. The only exception here will be the RedirectFromLoginPage() method.

   1:  using System;
   2:  using System.Data;
   3:  using System.Configuration;
   4:  using System.Collections;
   5:  using System.Web;
   6:  using System.Web.Security;
   7:  using System.Web.UI;
   8:  using System.Web.UI.WebControls;
   9:  using System.Web.UI.WebControls.WebParts;
  10:  using System.Web.UI.HtmlControls;
  11:  using ZooApplication.Library;
  13:  namespace ZooApplication.Website
  14:  {
  15:      public partial class Login : System.Web.UI.Page, ZooApplication.Library.ILoginView
  16:      {
  18:          public string EmailAddress
  19:          {
  20:              get
  21:              {
  22:                  return TxbEmailAddress.Text;
  23:              }
  24:              set
  25:              {
  26:                  TxbEmailAddress.Text = value;
  27:              }
  28:          }
  30:          public string ErrorMessage
  31:          {
  32:              get
  33:              {
  34:                  return LblErrorMsg.Text;
  35:              }
  36:              set
  37:              {
  38:                  LblErrorMsg.Text = value;
  39:              }
  40:          }
  42:          public string Password
  43:          {
  44:              get
  45:              {
  46:                  return TxbPassword.Text;
  47:              }
  48:              set
  49:              {
  50:                  TxbPassword.Text = value;
  51:              }
  52:          }
  54:          public Button BtnLogin
  55:          {
  56:              get
  57:              {
  58:                  return PageBtnLogin;
  59:              }
  60:              set
  61:              {
  62:                  PageBtnLogin = value;
  63:              }
  64:          }
  66:          public void RedirectFromLoginPage()
  67:          {
  68:              FormsAuthentication.RedirectFromLoginPage(this.EmailAddress, false);
  69:          }
  70:      }
  71:  }


The model

It’s our model that is responsible to validate the user login and password against the DB. 

We create a DB named ZooDB:

  • Add an APP_Data folder to your ZooWebsite project
  • APP_Data, new item, Database

Execute this script to create a table Profiles on the ZooDB:

CREATE TABLE [dbo].[Profiles](
      [ProfileID] [int] IDENTITY(1,1) NOT NULL,
      [EmailAddress] [nvarchar](255) NOT NULL,
      [Password] [nvarchar](255) NOT NULL,
      [ProfileID] ASC

Now configure your web.config file to add the connectionstring and the authentication part:

<?xml version="1.0"?>
    <add name="ZooDB" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=.\App_Data\ZooDB.mdf;Integrated Security=True"/>
      <authentication mode="Forms">
        <forms name="AuthCookie" path="/" loginUrl="login.aspx" protection="All" timeout="10">
        <deny users="?"/>


Test the application, it should compile and we should be redirected to the login page


Our model implements an Authenticate method. Again we will make use of interfaces to decouple the model from the controller.

On the ZooLibrary project create an interface ILoginModel:

   1:  namespace ZooApplication.Library
   2:  {
   3:      public interface ILoginModel
   4:      {
   5:          bool Authenticate(string emailAddress, string password);
   6:      }
   7:  }


The method Authenticate of the class LoginModel will check the validity of supplied email address and password.  You can implement the model with your preferred data access code.  Personally I use Subsonic because it’s really simple to use and it’s based on the active record pattern, the same pattern used in Rails.

But for the moment let’s use standard ADO.NET code:

   1:  using System;
   2:  using System.Collections.Generic;
   3:  using System.Text;
   4:  using System.Data.SqlClient;
   5:  using System.Configuration;
   7:  namespace ZooApplication.Library
   8:  {
   9:      public class LoginModel : ILoginModel
  10:      {
  11:          public bool Authenticate(string emailAddress, string password)
  12:          {
  13:              SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["ZooDB"].ConnectionString);
  14:              SqlCommand cmd = new SqlCommand(
  15:                  "SELECT count(EmailAddress) FROM [Profiles] " +
  16:                  "WHERE EmailAddress=@EmailAddress AND Password=@Password",
  17:                  conn);
  18:              cmd.Parameters.AddWithValue("@EmailAddress", emailAddress);
  19:              cmd.Parameters.AddWithValue("@Password", password);
  20:              try
  21:              {
  22:                  conn.Open();
  23:                  if((int)cmd.ExecuteScalar()==1)
  24:                      return true;
  26:                  return false;
  27:              }
  28:              finally
  29:              {
  30:                  conn.Close();
  31:              }
  32:          }
  33:      }
  34:  } 

The controller

The controller job is to figure out how the view should display the model. Therefore the controller should have an association with the model and the view.

  • Add a new class to ZooLibrary name it LoginController.

We start by defining a constructor that takes a ILoginView and a ILoginModel as parameters.
The Initialize method will be called by the page to instruct the controller to take control over the view and the model.
In the initialize method we will prepare the view to be rendered and subscribe to the events triggered by the view.

   1:  using System;
   2:  using System.Collections.Generic;
   3:  using System.Text;
   5:  namespace ZooApplication.Library
   6:  {
   7:      public class LoginController
   8:      {
   9:          private ILoginView _view;
  10:          private ILoginModel _model;
  13:          public LoginControler(ILoginView view, ILoginModel model)
  14:          {
  15:              this._view = view;
  16:              this._model = model;         
  17:          }
  19:          public void Initialize()
  20:          {
  21:              this._view.ErrorMessage = "";
  22:              this._view.BtnLogin.Click += new EventHandler(BtnLogin_Click);
  23:          }
  25:          public void BtnLogin_Click(object sender, EventArgs e)
  26:          {
  27:              if (this._model.Authenticate(this._view.EmailAddress, this._view.Password))
  28:                  this._view.RedirectFromLoginPage();
  29:              else
  30:                  this._view.ErrorMessage = "Invalid emailaddress or password!";
  31:          }
  32:      }
  33:  }



Integrating the MVC into the page

When we program against an asmx page it’s always the page that receive the initial control from the ASP.NET framework.
So it’s the page that need to instantiate the model, the view and the controller.

   1:      public partial class Login : System.Web.UI.Page, ZooApplication.Library.ILoginView
   2:      {
   3:          private LoginController controller;
   5:          protected override void OnInit(EventArgs e)
   6:          {
   7:              base.OnInit(e);
   9:              ILoginModel model = new LoginModel();
  10:              controller = new LoginController(this, model);
  11:          }
  12:          protected void Page_Load(object sender, EventArgs e)
  13:          {
  14:              controller.Initialize();
  15:          }
  17:       }


We are now able with the help of mocking frameworks to test the logic in the model and the controller.

The code here uses NMock but you can use your prefered mocking framework to implement your tests:
In the meantime the test for our LoginController should look like this:

   1:  public void LoginController_LoginTest()
   2:          {
   3:              ILoginView view = mocks.NewMock<ILoginView>();
   5:              ILoginModel model = mocks.NewMock<ILoginModel>();
   6:              LoginController target = new LoginController(view, model);
   8:              Expect.AtLeastOnce.On(view).GetProperty("BtnLogin").Will(Return.Value(new System.Web.UI.WebControls.Button()));
   9:              Expect.AtLeastOnce.On(view).GetProperty("EmailAddress").Will(Return.Value(""));
  10:              Expect.AtLeastOnce.On(view).GetProperty("Password").Will(Return.Value("password"));
  11:              Expect.Once.On(model).Method("Authenticate").With(view.EmailAddress, view.Password).Will(Return.Value(true));
  12:              Expect.Once.On(view).SetProperty("ErrorMessage").To("");
  13:              Expect.AtLeastOnce.On(view).Method("RedirectFromLoginPage");
  15:              target.Initialize();
  16:              target.BtnLogin_Click(view.BtnLogin, null);
  18:              mocks.VerifyAllExpectationsHaveBeenMet();
  20:          }

I hope this introduction to the MVC pattern has been profitable to you.


kick it on

GIT with VisualStudio

It’s about a week that I’m trying to use Git with Visual Studio. My intention was to replace SVN by Git because it allows for a more complete development workflow.

The idea is that you can make local commits of your changes and when the changes are mature enough they can be pushed on a central Git or SVN repository. This provides more flexibility and shorten the time between two commits. 

I found the experience of working with a local source controller very convenient and I’m  convinced that this model will soon be adopted on all platforms.  Nevertheless my experience with Git was not completely positive and I’m not planning (any more) to abandon SVN/Ankh/Tortoise. I’m sure that Git makes a perfect fit when developing on Linux but my experience on Windows/VisualStudio was mitigated.

These are my list of pro’s and con’s.

  • Enables local commits
  • Very lightweight
  • Command line tools are simple and powerful
  • Branching, Merging and Taggging are easy and reliable
  • Good integration with Windows through TortoiseGit
  • Perfect integration with SVN (you can use Git as a client for SVN)


  • Lack of integration with VisualStudio. I tried Git Extensions but compared to AnkhSVN this tool is just a buggy toy.
  • No mature hosting providers. GitHub is the primary repository for Git in the cloud, the one I tested. Frankly I found their security mode (SSH key) not user friendly. Also the tracking tools are poor and at least confusing compared to an Assembla.

Because of these relatively important problems I plan to continue using SVN for the moment. Nevertheless when I need a small local source controller (e.g. when giving courses/presentation) Git is definitely the way to go. Also I plan to use Git when I’m disconnected from the SVN repository for more than a day.


Kata2: The Decorator Pattern


This the second part of the series of Coding Kata’s. Here we’ll explore the Decorator pattern.

This is the user story:

You need to send alerts to your customers when a new product is available. 
An Alert is represented by the Alert Class:

public class Alert
      public String DestinationAddress { get; set; }
      public String SenderAddress { get; set; }
      public String Content { get; set; }
      public string Log { get; set; }

Classes used to send the Alerts implement the following interface:

public interface ISender
        void Send(Alert alert);


  • Create an Alerter class that send the appropriate alerts.  
  • Alerts are always send by e-mail.
  • Customers can also subscribe to receive alerts via sms and/or through messenger. 
  • Use the Decorator pattern to configure the Alerter

    You do not need to use real infrastructure code to send the alert, just append a string that contains the Sender through which the message was send.
    ->Append the following text to the Alert.Log when the message is send by:
  • e-mail      : “Message was send by e-mail”
  • sms         : “Message was send by sms”
  • messenger: “Message was send by messenger”


Show Solution


Coding Kata on design patterns: Kata1, The Abstract Factory Pattern


This post is the first in a series dedicated to Coding Kata’s and design patterns.  

Because I’m not always able to remember all the patterns I decided to learn by practice.  

Every week I will try to create a Kata with a simple problem that has to be resolved with one of the Gov’s design patterns.  

Because I want to start smoothly we’ll start with one of the simplest pattern -> the Abstract Factory.

Kata1 ->

- A product has a property Name.  

- Because the Name is used as an identifier it can’t be changed.  

- We need to be able to construct 2 products with following names: Product1, Product2.

- Use the abstract factory pattern so that you’re able to create Products.


This is my solution for Kata1.



Sharepoint 2007 Certification Guide

Here under you can find two usefull ressources to prepare for the exam:


-       The Wrox book: Professional Sharepoint 2007 Development


-       The Blog of: Adam Roderick


By focusing primarily on these two resources I managed to pass the Sharepoint Certification with what could be considered a ‘high score’. 

Create a WCF service and client, using Msmq, programmatically

  download source code

Most of the WCF examples on the web uses the config file to setup the address, binding and contract of a WCF service. I dislike this way of configuring client and service in WCF because most of the time it leads to config files that are full of crab and that becomes unmanageable. I prefer to construct my WCF services programmatically. Therefore I’ve create a bunch of helper classes that contains most of the configuration settings that are applicable in a particular domain.

In this article I discuss one of these classes  I use to create local queues. With local I mean queues used by components making part of the same application. This class can be used as a factory to create the service (serviceHost) as well as the client part (Channel) for components communicating through Msmq.

This article provides a small tutorial on how to create a simple console app. I demonstrate how to create the client and service host without any configuration by using a helper factory class: WCFMsmqFactory


- This article assumes you’ve installed Msmq on your box.  If this isn’t the case install Msmq see->  here for Xp & Win server 2003 or here for Vista & Win 2008 & Seven.

- If you’re a vista user you need to register your namespace for by typing in the command (in administrator mode):
netsh http add urlacl url=http://+:8000/BackToOwner/gatewayservice/sms user=[your username]

1) Create a new console application project: ‘WCFMsmqFactory’ and add a reference to

  • System.ServiceModel
  • System.Messaging
  • System.Transactions


2) Create a the WcfMsmqFactory class by copying the source code here beneath:

   1:  public class WcfMsmqFactory<I, T> where T : I
   2:     {
   3:         private string _queueAddress;
   4:         public WcfMsmqFactory(string queueAddress)
   5:         {
   6:             _queueAddress = queueAddress; 
   8:             if (!MessageQueue.Exists(queueAddress))
   9:                 MessageQueue.Create(queueAddress, true);
  10:         } 
  12:         public ServiceHost CreateMsmqServiceHost(string metadataAddress, string namespaceName)
  13:         {
  14:             var sHost = new ServiceHost(typeof(T));
  15:             var binding = new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None);
  16:             binding.DeadLetterQueue = DeadLetterQueue.System;
  17:             binding.Namespace = namespaceName;
  18:             sHost.AddServiceEndpoint(typeof(I),
  19:                                            binding,
  20:                                            new Uri(String.Format(
  21:                                                        @"msmq.formatname:DIRECT=OS:{0}",
  22:                                                        _queueAddress)
  23:                                                )
  24:                 ); 
  26:             // Expose the service metadata on the metadataAddress
  27:             var smb = new ServiceMetadataBehavior();
  28:             smb.HttpGetEnabled = true;
  29:             smb.HttpGetUrl = new Uri(metadataAddress);
  30:             sHost.Description.Behaviors.Add(smb); 
  32:             return sHost;
  33:         } 
  35:         public I CreateChannel()
  36:         {
  37:             var binding = new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None);
  38:             var address = new EndpointAddress(String.Format("msmq.formatname:DIRECT=OS:{0}", _queueAddress));
  39:             var channelFactory = new ChannelFactory<I>(binding, address);
  40:             return channelFactory.CreateChannel();
  41:         }
  42:     }

This class is perfectly reusable in any project and provide an abstraction on how to create programaticaly WCF services using the msmq binding. To instantiate the class we’ve to pass the interface and his actual implementation. The interface type we’ll be used to create the client & server part. The implementation type (service) will only be used to create the server.
The constructor creates a queue if it’s not already available. Note that the example don’t use security as the transport level security would demand to use active directory. As my pc does not connect to an Active Directory server I had to instantiate the binding without security:

var binding = new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None);

Not setting this setting resulted to the following error message: ” Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled. The channel factory or service host cannot be opened”

For the dead letter queue I use the default dead letter queue (see comment) settings:

binding.DeadLetterQueue = DeadLetterQueue.System;

To prevent the service to display the namespace as it’s important to provide the same namespace settings as in your service contract & behavior directive.

binding.Namespace = namespaceName;

The following code exposes the metadata information (wsdl) on the provided metadata address:

var smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true;
smb.HttpGetUrl = new Uri(metadataAddress);

3) Now lets create the message definition.
Add a new class SmsMessage:

public class SmsMessage
        public string Number { get; set; }
        public string Body { get; set; }

4) Define the service definition:
Add the file SmsService.cs:

   1:  [ServiceContract(Namespace = "http://My.Domain.Services.WCF")]
   2:  [ServiceKnownType(typeof(SmsMessage))]
   3:  public interface ISmsService
   4:  {
   5:      [OperationContract(IsOneWay = true, Action = "*")]
   6:      void SubmitSms(MsmqMessage<SmsMessage> msg);
   7:  } 
   9:  [ServiceBehavior(Namespace = "http://My.Domain.Services.WCF")]
  10:  public class SmsService : ISmsService
  11:  {
  12:      public void SubmitSms(MsmqMessage<SmsMessage> msg)
  13:      {
  14:          var sms = msg.Body;
  15:          Console.WriteLine(string.Format(
  16:                                "SMS send to {0} with body='{1}'",
  17:                                sms.Number,
  18:                                sms.Body)
  19:              ); 
  21:      }
  22:  }

The SmsService class contains the real implementation code. As the purpose of this article is not to demonstrate how to actually send sms messages I didn’t provide the real code here. This demo only output the message on the console.

5) Finally let’s put all the parts together.
Add the following code to the main part of the program:

   1:   static void Main(string[] args)
   2:      {
   3:          //define variables
   4:          const string queueAddress = @".\private$\sms";
   5:          const string metadataAddress = "http://localhost:8000/BackToOwner/gatewayservice/sms";
   6:          const string nameSpaceName = "http://My.Domain.Services.WCF";
   7:          var message = new SmsMessage()
   8:                            {
   9:                                Number = "+322678821",
  10:                                Body = "This is a sample sms message!"
  11:                            };
  12:          var msmqMessage = new MsmqMessage<SmsMessage>(message); 
  14:          //define factory 
  15:          var factory = new WcfMsmqFactory<ISmsService, SmsService>(queueAddress); 
  17:          //Do the work
  18:          using(var serviceHost = factory.CreateMsmqServiceHost(metadataAddress,nameSpaceName))
  19:          {
  20:              Console.WriteLine("Starting the server...");
  21:              serviceHost.Open();
  22:              Console.WriteLine("Instantiating the client channel...");
  23:              var channel = factory.CreateChannel();
  24:              using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
  25:              {
  26:                  Console.WriteLine("Sending the message...");
  27:                  channel.SubmitSms(msmqMessage);
  28:                  scope.Complete();
  29:              }
  30:              Thread.Sleep(1000);
  31:              Console.WriteLine("Closing the server...");
  32:              serviceHost.Close();
  33:          }
  34:          Console.ReadLine();
  35:      }
  36:  }

   Running the application should display a console with:
Starting the server...
Instantiating the client channel...
Sending the message...
SMS send to +322678821 with body='This is a sample sms message!'
Closing the server...

The real magic happens here:

var factory = new WcfMsmqFactory<ISmsService, SmsService>(queueAddress);

With this few line of code we’ve instantiated a factory that is able to create the client as the server of our service. The only thing we’ve to pass is the queue address – the rest of the configuration is encapsulated in our Factory class and can be easily reused.   We can provide our factory classes to all the enterprise and create a framework on top of WCF that will standardize and facilitate how WCF is used inside our company.


kick it on

The 5 Pilars of Unit Testing


These are, what I consider to be the 5 most desirable quality attributes of a unit test:
1.       Unit tests should be accessible, everyone should be able to run them
Running a unit test should not involve more than getting the source code from a source controller, compile the SUT/Test code and clicking on a button to run all the tests. No configuration should be involved. Your tests should not require to setup external components like a DB or SMTP server. 
2.       Unit tests should be repeatable
What is the value of a test you can’t trust? Unit tests results should only change when modifications are introduce in the SUT. When the SUT remain the same the unit tests should always return the same result. Therefore unit tests should be state independent and in anyway they should never be dependant on a shared resource like a file or persistent memory.
3.       Unit tests should be easy to write and maintain
In an software shop we should only use a practice or tool when this is economical viable meaning that the cost of writing the tests and maintaining it should not exceeds the costs of having a bug and fixing it. To minimize the cost of creating and maintaining tests we should use appropriate practices and tools. We should also have the same quality requirement for test code as for production code. Refactoring is as important for test code as for production code.   
4.       Unit tests should be resistant to change
We should write our test in such a way that the amount of tests failing when introducing a change is minimal. When testing the SUT it is common to set his variable in proper state so it can be tested. This type of setup test code is very fragile. We should always try to isolate this type of code so it is easy to change. 
5.       Unit tests should run quickly
ideally unit tests should be executed after every build. Having to wait more than 1 minute to execute all the unit tests will decrease the overall productivity of the tests. Unit tests should never be dependant on costly resources to invoke like web services or DB.
Is there someting missing here? 
View Geoffrey Vandiest's profile on LinkedIn

Extensibility for ASP.NET MVC


I’m working on an extensibility framework made to be used on top of ASP.NET MVC. My extensibility framework is based on the famous Ioc container: Structuremap .
The use case I’m trying to fulfill is simple: create an application that should have some basic functionality that can be extended for every customer (=multi-tenancy). There should only be one instance of the application hosted but this instance can be adapted for every customer without making any changes to the core website.
I was inspired by the article on multi tenacy wroted by Ayende Rahien: Another source of inspiration was the book of Eric Evans on Domain Driven Design. My Extensibility framework is based on the repository pattern and the concept of root aggregates. To be able to use the framework the hosting application should be build around repositories and domain objects. The controllers, repositories or domain objects are bind at runtime by the ExtensionFactory.
A plug-in is simply an asselmbly that contains Controllers or Repositories or Domain Objects that respects a specific naming convention. The naming convention is simple, every class should be prefixed by the customerID e.g.: AdventureworksHomeController.
To extend an application you copy a plug-in assembly in the extension folder of the application. When a user request a page under the customer root folder e.g:[customerID]/[controller]/[action] the framework check if there is a plug-in for that particular customer and instantiate the custom plug-in classes otherwise it loads the default once. The custom classes can be Controllers – Repositories or Domain Objects. This approach enables to extend an application at all levels, from the database to the UI, through the domain model, repositories.
When you want to extend some existing features you create a plug-in an assembly that contains subclasses of the core application. When you’ve to create totally new functionalities you add new controllers inside the plug-in. These controllers will be loaded by the MVC framework when the corresponding url is requested. If you want to extend the UI you can create a new view inside the extension folder and reference the view by a new or subclassed controller .To modify existing behavior you can create new repositories or domain objects or sub classing exiting ones. The framework responsibility is to determine which controller/ repository / domain object should be loaded for a specific customer.
I advise to have a look at structuremap ( and especially at the Registry DSL features .
This is the code I use at the startup of the application to register all plug-in controllers/repositories or domain objects:
protectedvoidScanControllersAndRepositoriesFromPath(string path)
this.Scan(o =>
AddAllTypesOf<SaasController>().NameBy(type => type.Name.Replace("Controller", ""));
AddAllTypesOf<IRepository>().NameBy(type => type.Name.Replace("Repository", ""));
AddAllTypesOf<IDomainFactory>().NameBy(type => type.Name.Replace("DomainFactory", ""));
I also use an ExtensionFactory inheriting from the System.Web.MVC. DefaultControllerFactory. This factory is responsible to load the extension objects (controllers/registries or domain objects). You can plugin your own factories by registering them at startup in the Global.asax file:
protectedvoid Application_Start()
l'll try to find some time to explain my approach more clearly on my blog and hopefully I'll be able to publish my Extesnsibility framework on CodePlex soon.

First Steps with Unit Testing Walkthrough

 In this article I introduce through a walkthrough the basics of how to write a good well structured unit test. This post is the first of a series about Unit testing and TDD. I’ll not be doing TDD for now because I first want to start with the basics of creating well structured unit tests.  In later posts we will build on this to practice TDD. Therefor the tests of this first walkthrough will seem overly simple, but let’s crawls before we start running.
The details on how we should write tests vary with the programming framework & unit test framework. For this walkthrough I've choosen to implement  the tests and examples witrh C# and VSTS .Nevertheless the core principle of how to implement automated tests stays applicable in any technology.  If you desire to get the walkthroughs for NUnit or for other programming frameworks post a demand in this blog.  You can download the completed walkthrough project here.


public class Fleet : IDisposable
private List _planes { get; set; }

public Fleet()
this._planes = new List();

public Plane this[string index]
return this._planes.Find(p => p.Name == index);

public void Add(string name)
this._planes.Add(new Plane(name));

public int Count
return this._planes.Count;

public void Dispose()
this._planes = null;

public class Plane
public Plane(string name)
this.Name = name;

public int PlaneID { get; set; }
public string Name { get; set; }


Examine the code of Fleet and Plane. The Fleet class represents an aero fleet (a simple Model) this class is a sort of collection of planes. The fleet class contains a property “Count” that counts the number of planes in the fleet.
Create a new Test Project File, right click solution, add, new, Project, select C#, Test, name your Project:”FirstStepsTest”.
Launch all tests: Ctrl R,A or Test, Windows, Test View
VS should launch the TestMethod1 and it should pass.

 Replace the generated TestMethod() with the following test:

public void NewFleet_WithNoPlanes_CountWillReturn0()
  Fleet fleet = new Fleet();

  int actual = fleet.Count;

  Assert.AreEqual(0, actual);

Run the test by right click on the test name and select “Run Test”.
The test above is a public method whose giving the attribute [TestMethod] the test class itself is been annotated with the attribute [TestClass]. This enable the testRunner of VSTS to retrieve all test methods.

Every test will always consist of 3 parts:
• The setup: to be able to test our SUT we’ve to put him in a certain state so it can be tested.
• The test execution: when our SUT is prepared to be test we can call the actual execution unit on our SUT.
• The verification: A test generally ends with the comparison on the expected results and the actual outcome of our execution.

The last part of our test uses an assertion method of our unit testing framework. Knowing what to assert about in your tests is pretty much 90% of the battle. An assertion is basically taking an expected value and comparing it to an actual value. If the expected value does not match the actual value, then the test will fail.

There are many other type of assertions but for simplicity and for readability when debuging I prefer to only use the Assert.Equals(). Assert equals is the most generic form of assertion and it will always display a meaningful message like Assert.AreEqual failed. Expected:. Actual:.Add following new tests to the test class:


public void Add_OnePlane_WillIncrementCountByOne()
Fleet fleet = new Fleet();


Assert.AreEqual(1, fleet.Count);

public void RetriveByIndex_APlane_WillReturnThePlane()
Fleet fleet = new Fleet();

String actual = fleet["X2938"].Name;

Assert.AreEqual("X2938", actual);

Examine the tests and run them, they should all pass.

We'll refactor a little bit our code because the test contains some parts of code that are repeated and repeating ourselves is always bad!
First we will remove the magic string: “X2938” and will instantiate a string field flightName containing this value. Replace “X238” with this new variable.
We will also promote the fleet object in each test to a new private field. We will use the [TestInitialize] attribute to instantiate this field.
Also imagine that our Fleet class implements IDisposable because it uses somehow an expensive resource that isn’t automatically disposed by the garbage collector. We could call fleet.Dispose() after the Assertion but what if our test fails? The dispose method would never been called and the object will remain in memory.
The result should look like that:

public class FleetTest
private Fleet fleet;
const string flightName = "X2938";

public void TestInitialize()
fleet = new Fleet();
} [TestCleanup()] public void TearDown() { fleet.Dispose(); }

public void NewFleet_WithNoPlanes_CountWillReturn0()

int actual = fleet.Count;

Assert.AreEqual(0, actual);

public void Add_OnePlane_WillIncrementCountByOne()


Assert.AreEqual(1, fleet.Count);

public void RetriveByIndex_APlane_WillReturnThePlane()

String actual = fleet[flightName].Name;

Assert.AreEqual(flightName, actual);

We've defined a SetUp() and TearDown() pair of methods. In major XUnit frameworks, these are used to create Fixtures. A Fixture is some resource all tests in a test case have in common and which sets the context of the test (the situation in which we're testing), as well as other repetitive objects or resources.
VSTS uses the attributes [TestInitialize()] for the Setup, this part is run before each test and [TestCleanup()] for the teardown, run after each test.
Because each test must be isolated (cannot share information) these methods will tell the Framework to create our Fixture (a Fleet instance) before each test, and destroy it after. So each test gets a shiny new version to play with, free of anything a previous test may have done.

The test case above is a good small start and I hope you enjoyed this first walkthrough on unit testing, don’t hesitate to post some feedback!


View Geoffrey Vandiest's profile on LinkedIn

Webservice Interoperability with contract first approach

We just solved an interoperability problem for one of our customer that was trying to interoperate between Java & .Net. He was using jaxws to generate his java proxy code and wcf (svcutil) for the .Net proxy . The customer had worked based on a contract first approach and tested his contract through jaxws. When he tried to generate the proxy classes for his .Net app, using svcutil, the generated proxy class was missing all the collections. He also had a runtime error when trying to serialize some messages. 

We rapidly found the cause of the missing collection. The customer had used maxOccurs="unbounded” in his wsdl, what is not supported by the DataContractSerializer used by svcutil. We replaced the unbounded with a 9999999 and suddenly the collections appeared in his proxy class. 
But the runtime error was still there L
After some research we found an interesting article on MSDN describing the subset of  WSDL supported by SVCUTIL. Based on the article we discovered that the customer had used a <choise> element in a complextype. This caused the SVCUTIL to use the old XMLSerializer in place of the DataContractSerializer  of WCF.   The XMLSerialzer made some strange construct in the proxy class causing runtime errors. So we simply removed the <choice> element and everything worked fine after that.