https://github.com/JorritSalverda/msbuild-by-convention

In this article I describe how to use them on your workstation, in your Continuous Integration/Delivery server and what parts still need a bit more attention.

What are the goals?

• To be able to set up a new project with as little effort as possible to avoid having any projects that live without CI, because of the lack of time to set it up. To reduce setup time the scripts favor convention over configuration.
• To be able to run all actions equally well from your workstation as from the build server.

What does it automate for you?

The scripts are continuously improving, currently they do quite a lot:

Compilation

• Versions all your compiled assemblies with parameter BuildVersion, which needs a major.minor.build.revision (1.5.13.859 for example) version number.
• For both MVC and WebForms applications it compiles views using AspNetCompiler.
• Outputs your generated assemblies to a set directory, so solutions can reference assemblies generated in another solution within the same repository.

Testing

• Runs test created with both NUnit and Machine.Specification.
• Runs JMeter tests.

Creating release artifacts

• Minifies CSS and Javascript grouped per directory with YUI Compressor and versions the filename to avoid any caching issues after deploy.
• Compiles Flash with Flex, outputs it to your web project and versions the filename.
• Applies config transforms for any config file (where the original is called [a-z]+.config and the transform [a-z]+.[a-z]+.config).
• Creates artifacts for each environment you have a config transform for.
• Updates filenames with 1.0.0.0 in them to reflect the build version to avoid caching issues and updates all references to them in css and js.
• Precompiles asp.net websites.
• Removes any files that shouldn’t be part of the release.
• Optimizes pngs.
• Optimizes jpegs.

Deploying release artifacts

• Deploys websites using MSDeploy.
• Deploys database projects.
• Deploys data-tier-applications (supported by Azure).
• Deploys Azure packages to staging, then swaps to production and removing staging afterwards; which of these steps is executed can be parameterized.

Various

• Delete Azure instances.
• Analyze code using FXCop.

Which actions are taken for what projects is automatically handled by sticking to the project naming conventions. More about these below.

Read on to learn how the build files are structured, how to use them and how to configure them in your favorite CI server.

Structure

The project has the following MSBuild files:

1. properties-convention-based.msbuild
2. properties-repository-specific.msbuild
3. targets.msbuild
4. targets-repository-specific.msbuild

The first and third are the ones that continuously get improved so are best left untouched after you first start using them except for updating them to the newest version; the second and fourth allow you to override any defaults as defined in the other two files and have no need to be updated to the newest version.

The other scripts used from targets.msbuild are

• AzureDelete.ps1
• AzureDeploy.ps1
• DacDeploy.ps1

If you inspect properties-convention-based.msbuild you can see that the directory structure as used in the repository is defined there and that the following conventions for project names are used:

• *.Website.csproj
• *.WebService.csproj
• *.Console.csproj
• *.Service.csproj
• *.Database.dbproj
• *.Worker.csproj
• *.Azure.ccproj
• *.UnitTests.csproj
• *.IntegrationTests.csproj

For the location of your css and javascript within a Website project the following conventions are used:

• static\css
• static\js

Within these directories the contents of each sub-directory will be merged and minified. In the case of css the resulting file is stored in the sub-directory (so all relative paths stay intact), for javascript it’s stored in the static/js directory.

Any of the conventions can be overridden, this is best done in the properties-repository-specific.msbuild file, so you can still easily update properties-convention-based.msbuild and targets.msbuild to the newest version.

Getting started

To get this stuff on the road the following steps need to be taken:

1. Make sure you have Visual Studio 2010 SP1 installed.
2. Fork https://github.com/JorritSalverda/msbuild-by-convention or download as a zip and extract to your repository.
3. Get at least the following tools and add their files in the respective /Build/Tools/ sub-directory:
4. Compile – MSBuild.Community.Tasks.v1.2.0.306
5. Compile - MSBuild.ExtensionPack.Binaries.v4.0.2.0
6. Run unit/integration tests – NUnit-2.6.0.12051
7. Run unit/integration tests - Machine.Specifications.0.5.6.0
8. Create release - Yahoo.Yui.Compressor.v1.6.0.2
9. Create release - optipng-0.7.1-win32
10. Create release - Jpegtran
11. Create release - VS2010WebPublishing
12. Create release - Windows.Azure.Tools.v1.6
13. Deploy vs2010 studio database projects - Vs2010DbCmd
14. Deploy data-tier applications - SqlPowershell-10.50.1600.1
15. Deploy websites via MSDeploy - MsDeploy.v2
16. Deploy websites to Azure – install Azure powershell commandlets.
17. Run Jmeter tests - apache-jmeter-2.6
18. Analyze code quality - FxCop.v10.0

I’ll soon check which of these tools can be included in the repository without being in conflict with their license in order to avoid step 3 and following.

Deploying to Azure and deploying data-tier applications both use Powershell scripts. As these aren’t signed they would normally be blocked for execution. To enable unsigned scripts to be executed start the Powershell and run the following command:

set-executionpolicy unrestricted

This does put your machine at risk, but it’s currently the only way I know how to enable the execution of those scripts.

Running the scripts

Okay, after all this work it is time to really get started. From a visual studio command line navigate to the /Build/Scripts/ directory and use the following commands.

To compile all solutions in the /Source/Csharp/ directory and subdirectories perform the following command:

msbuild.exe targets.msbuild /t:Build

To run all unit test projects:

msbuild.exe targets.msbuild /t:RunUnitTests

To create release artifacts for all your projects in the /Build/Releases/ directory:

msbuild.exe targets.msbuild /t:Release

To run all integration test projects:

msbuild.exe targets.msbuild /t:RunIntegrationTests

To deploy VS2010 database projects or Data-Tier Applications:

msbuild.exe targets.msbuild /t:Deploy /p:ReleaseConfiguration=”PROD” /p:ProjectToDeploy=”Projectname.Database” /p:DeployServer=”database-server-name” /p:DeployTargetName=”database-name” /p:DeployUsername=”db-admin-name” /p:DeployPassword=”db-admin-password”

To deploy a website with MSDeploy to an IIS server:

msbuild.exe targets.msbuild /t:Deploy /p:ReleaseConfiguration=”ACC” /p:ProjectToDeploy=”Projectname.Website” /p:DeployServer=”iis-server-name” /p:DeployTargetName=”iis-website-name” /p:DeployUsername=”deploy-user-name” /p:DeployPassword=”deploy-user-password”

To deploy an Azure web role or worker role:

msbuild.exe targets.msbuild /t:Deploy /p:DeployEnvironment=”PROD” /p:ProjectToDeploy=”Projectname.Azure” /p:AzureSubscriptionID=”subscription-id” /p:AzureCertificatePassword=”management-certificate-password” /p:AzureHostedServiceName=”hosted-service-name” /p:AzureStorageAccountName=”storage-account-name” /p:AzureSwapToProductionAfterDeploy=”True” /p:AzureRemoveStagingAfterSwap=”True” /p:AzureDisallowMultipleActiveInstances=”False”

To enable deployments to Azure you need to store a management certificate at /Build/Scripts/AzureManagementCertificate.pfx. The RunUnitTests and Release targets depend on the Build target being executed; the Deploy targets depend on the Release target. With these separate commands you can easily set up a pipeline within your CI server.

Setting up a Continuous Delivery pipeline

A possible pipeline set up can look like the one pictured below.

To implement this you would call the following targets and actions:

1 Compile

• target: Build

2 Run unit tests

• target: RunUnitTests

3 Create release

• target: Release
• save Release artifacts from directory /Build/Releases/

4 Deploy to INTEGRATION + run integration tests

• fetch Release artifacts
• target: Deploy for database
• target: Deploy for website (using MSDeploy or deploy to Azure)
• target: RunIntegrationTests
• target: RunJMeterTests

5 Deploy to ACCEPTANCE

• fetch Release artifacts
• target: Deploy for database
• target: Deploy for website (using MSDeploy or deploy to Azure)

6 Deploy to PRODUCTION

• fetch Release artifacts
• target: Deploy for database
• target: Deploy for website (using MSDeploy or deploy to Azure)

When you set this up in Teamcity you would like to make sure the separate steps have a snapshot dependency on the previous step, the same version number is used for every step (use %dep… as version number, after setting up the snapshot dependency) and the steps that use the Release artifacts have an artifact dependency to step 3.

In Bamboo you have no such thing as a snapshot dependency, so in that case I save the whole working copy as an artifact in step 1 and have every following step import this artifact. From step 3 and further it also has a dependency on the Release artifact.

Where Teamcity and CruiseControl automatically pass their version numbers to the scripts in Bamboo you have to do this explicitly by adding the following parameter:

/p:BuildVersion=1.0.0.${bamboo.buildNumber}

What needs to be improved?

Of course there are still a lot of improvements on the wish list:

• Reduce the ‘getting started’ to 2 steps by adding the necessary /Build/Tools to the repository where their respective licenses allow for that.
• Remove the need for Visual Studio and SQL Server to be installed on a build agent.
• Support Robocopy.
• Handle first time deploy to Azure, not needing a first manual deploy.
• Deploy certificates to Azure.
• Add Selenium testing.
• Make it more extendable.
• Determine code coverage.

Let me know if any parts of the setup are unclear so I can document them into more depth. I can also provide you with the /Build/Tools directory zipped up, until I’ve figured that out, license-wise.

Cheers, Jorrit

By using the form models as spoken about in View Model and Form Model the need for custom binding doesn’t arise to often anymore.

But every now and then we have some duplicate code doing something with incoming parameters. Perhaps we can move this logic into a binder to be more DRY. Or if our form model has types that MVC can’t bind automatically – like enumerations – custom binding comes into play.

MVC is extensible on the part of binding form data or get parameters to your method parameters. You can define your own binders and have them work for certain types.

SmartBinder

Jimmy Bogard wrote a very helpful class called SmartBinder, which you can read all about over here. We use it for all our custom binders. You can see the neccessary code below:

public interface IFilteredModelBinder : IModelBinder
{
	bool IsMatch(Type modelType);

	new BindResult BindModel(ControllerContext controllerContext,
							 ModelBindingContext bindingContext);
}

public class SmartBinder : DefaultModelBinder
{
	private readonly IFilteredModelBinder[] filteredModelBinders;

	public SmartBinder(IFilteredModelBinder[] filteredModelBinders)
	{
		this.filteredModelBinders = filteredModelBinders;
	}

	public override object BindModel(ControllerContext controllerContext,
									 ModelBindingContext bindingContext)
	{
		foreach (var filteredModelBinder in filteredModelBinders)
		{
			if (filteredModelBinder.IsMatch(bindingContext.ModelType))
			{
				BindResult result = filteredModelBinder.BindModel(controllerContext,
																  bindingContext);
				bindingContext.ModelState.SetModelValue(bindingContext.ModelName,
														result.ValueProviderResult);

				return result.Value;
			}
		}

		return base.BindModel(controllerContext, bindingContext);
	}
}

public class BindResult
{
	public object Value { get; private set; }

	public ValueProviderResult ValueProviderResult { get; private set; }

	public BindResult(object value, ValueProviderResult valueProviderResult)
	{
		Value = value;
		ValueProviderResult = valueProviderResult ??
								new ValueProviderResult(null,
														string.Empty,
														CultureInfo.CurrentCulture);
	}
}

Setting it up with StructureMap

To have MVC use this SmartBinder as the default binder we add the following line to the Application_Start method in the global.asax.cs:

ModelBinders.Binders.DefaultBinder = ObjectFactory.GetInstance<SmartBinder>();

And for setting up the list of binders implementing the IFilteredModelBinder interface neccessary for them to work from within the SmartBinder we add the following StructureMap registry:

public class BinderRegistry : Registry
{
	public BinderRegistry()
	{
		For<IFilteredModelBinder>().Add<EnumBinder<SomeEnumeration>>()
		 .Ctor<SomeEnumeration>().Is(SomeEnumeration.FirstValue);
		For<IFilteredModelBinder>().Add<EnumBinder<AnotherEnumeration>>()
		 .Ctor<AnotherEnumeration>().Is(AnotherEnumeration.FifthValue);
	}
}

Because the SmartBinder is instantiated with ObjectFactory.GetInstance<SmartBinder>() and it expects an array of IFilteredModelBinders, the For<IFilteredModelBinder>().Add<…>() makes sure StructureMap returns all defined binders if an IEnumerable of IFilteredModelBinder is needed for instantiating a class.

For a simple example of an IFilteredModelBinder I’ll show you the very useful EnumBinder.

EnumBinder

For binding enumerations Rupert Bates has this custom binder, which
looks as follows when having it implement the IFilteredModelBinder interface:

public class EnumBinder<T> : DefaultModelBinder, IFilteredModelBinder
{
	private readonly T defaultValue;

	public EnumBinder(T defaultValue)
	{
		this.defaultValue = defaultValue;
	}

	public bool IsMatch(Type modelType)
	{
		return modelType == typeof (T);
	}

	BindResult IFilteredModelBinder.BindModel(ControllerContext controllerContext,
											  ModelBindingContext bindingContext)
	{
		T result = bindingContext.ValueProvider[bindingContext.ModelName] == null
					? defaultValue
					: GetEnumValue(defaultValue,
				bindingContext.ValueProvider[bindingContext.ModelName].AttemptedValue);

		return new BindResult(result, null);
	}

	private static T GetEnumValue(T defaultValue, string value)
	{
		T enumType = defaultValue;

		if ((!String.IsNullOrEmpty(value)) && (Contains(typeof (T), value)))
		{
			enumType = (T) Enum.Parse(typeof (T), value, true);
		}

		return enumType;
	}

	private static bool Contains(Type enumType, string value)
	{
		return Enum.GetNames(enumType).Contains(value,
												StringComparer.OrdinalIgnoreCase);
	}
}

For MVC 2 the EnumBinder looks a bit different:

public class EnumBinder<T> : DefaultModelBinder, IFilteredModelBinder
{
	private readonly T defaultValue;

	public EnumBinder(T defaultValue)
	{
		this.defaultValue = defaultValue;
	}

	public bool IsMatch(Type modelType)
	{
		return modelType == typeof(T);
	}

	BindResult IFilteredModelBinder.BindModel(ControllerContext controllerContext,
											  ModelBindingContext bindingContext)
	{
		T result =
			bindingContext.ValueProvider.GetValue(bindingContext.ModelName) == null
			? defaultValue
			: GetEnumValue(defaultValue,
		bindingContext.ValueProvider.GetValue(bindingContext.ModelName).AttemptedValue);

		return new BindResult(result, null);
	}

	private static T GetEnumValue(T defaultValue, string value)
	{
		T enumType = defaultValue;

		if ((!String.IsNullOrEmpty(value)) && (Contains(typeof(T), value)))
		{
			enumType = (T)Enum.Parse(typeof(T), value, true);
		}

		return enumType;
	}

	private static bool Contains(Type enumType, string value)
	{
		return Enum.GetNames(enumType).Contains(value,
												StringComparer.OrdinalIgnoreCase);
	}
}

We don’t have to explicitly add the binder in Application_Start like Rupert does, because StructureMap handles it for us through the BinderRegistry.

Testing the binder

Of course testing the binder is hard again, because of the ControllerContext and ModelBindingContext, but it can be done with the following code:

[TestFixture]
public class EnumBinderTests
{
	private IFilteredModelBinder binder;

	[SetUp]
	public void Setup()
	{
		binder = new EnumBinder<TestEnum>(TestEnum.ValueB);
	}

	[Test]
	public void IsMatchShouldReturnTrueIfTypeIsSameAsGenericType()
	{
		// act
		bool isMatch = binder.IsMatch(typeof(TestEnum));

		// assert
		Assert.That(isMatch, Is.True);
	}

	[Test]
	public void IsMatchShouldReturnFalseIfTypeIsNotSameAsGenericType()
	{
		// act
		bool isMatch = binder.IsMatch(typeof(string));

		// assert
		Assert.That(isMatch, Is.False);
	}

	[Test]
	public void BindModelShouldReturnEnumValueForWhichValueAsStringIsPosted()
	{
		// arrange
		ControllerContext controllerContext = GetControllerContext();
		ModelBindingContext bindingContext = GetModelBindingContext(
									new ValueProviderResult(null, "ValueA", null));

		// act
		BindResult bindResult = binder.BindModel(controllerContext, bindingContext);

		// assert
		Assert.That(bindResult.Value, Is.EqualTo(TestEnum.ValueA));
	}

	[Test]
	public void BindModelShouldReturnDefaultValueIfNoValueIsPosted()
	{
		// arrange
		ControllerContext controllerContext = GetControllerContext();
		ModelBindingContext bindingContext = GetModelBindingContext(null);

		// act
		BindResult bindResult = binder.BindModel(controllerContext, bindingContext);

		// assert
		Assert.That(bindResult.Value, Is.EqualTo(TestEnum.ValueB));
	}

	[Test]
	public void BindModelShouldReturnDefaultValueIfUnknownValueIsPosted()
	{
		// arrange
		ControllerContext controllerContext = GetControllerContext();
		ModelBindingContext bindingContext = GetModelBindingContext(
									new ValueProviderResult(null, "Unknown", null));

		// act
		BindResult bindResult = binder.BindModel(controllerContext, bindingContext);

		// assert
		Assert.That(bindResult.Value, Is.EqualTo(TestEnum.ValueB));
	}

	[Test]
	public void BindModelShouldReturnDefaultValueIfDefaultValueAsStringIsPosted()
	{
		// arrange
		ControllerContext controllerContext = GetControllerContext();
		ModelBindingContext bindingContext = GetModelBindingContext(
									new ValueProviderResult(null, "ValueB", null));

		// act
		BindResult bindResult = binder.BindModel(controllerContext, bindingContext);

		// assert
		Assert.That(bindResult.Value, Is.EqualTo(TestEnum.ValueB));
	}

	private static ControllerContext GetControllerContext()
	{
		return new ControllerContext
			{
				HttpContext = MockRepository.GenerateMock<HttpContextBase>()
			};
	}

	private static ModelBindingContext GetModelBindingContext(
										ValueProviderResult valueProviderResult)
	{
		ValueProviderDictionary dictionary = new ValueProviderDictionary(null)
		{
			{"enum", valueProviderResult}
		};

		return new ModelBindingContext
			{
				ModelName = "enum",
				ValueProvider = dictionary
			};
	}
}

public enum TestEnum
{
	ValueA,
	ValueB
}

You’ll probably want to make some shared methods in a unit test library for mocking different types of contexts, because you’ll need them often when testing an attribute or binder.

If your custom binder has some dependencies it’s also useful to do the unit test setup with AutoMocker, as shown in Poor Man’s RenderAction.

It keeps amazing me that every time I see some example MVC code from Scott Guthrie, Phil Haack or one of our other MVC heroes, it keeps looking like this:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(BlogItem blogItem)
{
	if (ModelState.IsValid)
	{
		...
		return RedirectToAction("OtherAction");
	}

	return View(blogItem);
}

The big problem with this code is that it returns a view (on the highlighted line), while the method handles a POST. It seems like a very bad practice, because it disrupts the natural flow of your website. It makes it impossible to make use of your browser history (the back button) without running into a ‘this page is expired’ warning. Or your user could post the same data multiple times.

It is an annoyance which will definitely cost your website some visitors! So no more return View in a post method!

The simple pattern that makes these warnings something of the past is the Post-Redirect-Get pattern (PRG); it just states that a post should always be followed by a browser redirect.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(BlogItem blogItem)
{
	if (ModelState.IsValid)
	{
		...
		return RedirectToAction("OtherAction");
	}

	return RedirectToAction("Create");
}

If it is this simple, why do the MVC gurus return a view in their example? Well, to keep your form filled with the input the user just entered and to show the validation errors, after a redirect, takes a little extra effort. By default, MVC doesn’t remember your ModelState from one request to the next.

To make sure the ModelState is ported to the next request we use the ModelStateToTempDataAttribute from the MvcContrib project. If a controller is decorated with this attribute you no longer have to worry about showing validation errors in a form when using the PRG pattern.

ModelStateToTempDataAttribute

public class ModelStateToTempDataAttribute : ActionFilterAttribute
{
	public const string TempDataKey = "__MvcContrib_ValidationFailures__";

	public override void OnActionExecuted(ActionExecutedContext filterContext)
	{
		ModelStateDictionary modelState = filterContext.Controller.ViewData.ModelState;

		ControllerBase controller = filterContext.Controller;

		if(filterContext.Result is ViewResult)
		{
			// If there are failures in tempdata, copy them to the modelstate
			CopyTempDataToModelState(controller.ViewData.ModelState,
									 controller.TempData);
			return;
		}

		// If we're redirecting and there are errors, put them in tempdata instead
		// (so they can later be copied back to modelstate)
		if((filterContext.Result is RedirectToRouteResult
            || filterContext.Result is RedirectResult) && !modelState.IsValid)
		{
			CopyModelStateToTempData(controller.ViewData.ModelState,
									 controller.TempData);
		}
	}

	private void CopyTempDataToModelState(ModelStateDictionary modelState,
										  TempDataDictionary tempData)
	{
		if(!tempData.ContainsKey(TempDataKey))
		{
			return;
		}

		ModelStateDictionary fromTempData = tempData[TempDataKey]
												as ModelStateDictionary;
		if(fromTempData == null)
		{
			return;
		}

		foreach(KeyValuePair<string,ModelState> pair in fromTempData)
		{
			if (modelState.ContainsKey(pair.Key))
			{
				modelState[pair.Key].Value = pair.Value.Value;

				foreach(ModelError error in pair.Value.Errors)
				{
					modelState[pair.Key].Errors.Add(error);
				}
			}
			else
			{
				modelState.Add(pair.Key, pair.Value);
			}
		}
	}

	private static void CopyModelStateToTempData(ModelStateDictionary modelState,
												 TempDataDictionary tempData)
	{
		tempData[TempDataKey] = modelState;
	}
}

The attribute only saves ModelState to TempData if there are validation errors. And if the next action returns a view, the ModelState is retrieved from TempData. TempData itself is a wrapper around Session-State in which objects are only present until the next request.

All we have to do now is to make use of this attribute is to apply it to each controller where needed:

[ModelStateToTempData]
public HomeController : Controller
{

I’ve read some comments from people who want to have more control and split the attribute in one writing to TempData and the other retrieving it. But this leads to a proliferation of attributes throughout your code. I can’t think of single moment I ever had need for finer-grained control than just applying the one attribute to the controller as a whole.

The drawback

Of course there is one caveat for the use of this attribute. It saves data in TempData, which is saved in Session-State. If the sites you build run on multiple machines behind a load balancer you can’t handle subsequent requests by different machines, unless they share their Session-State.

For the smaller sites we choose to set the load balancer in sticky mode, so a user will be coupled to the same server during his/her session. In this case, having multiple servers doesn’t really increase availability, in that a user will still hit the same server after it has crashed.

For storing Session-State MSDN shows us we have the following options:

• InProc mode, which stores session state in memory on the Web server. This is the default.
• StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• Custom mode, which enables you to specify a custom storage provider.
• Off mode, which disables session state.

If we don’t take the sticky road and need to share Session-State between multiple servers we’ll have to go for the StateServer or SQLServer option. Both necessitate that the items stored in session are serializable.

More on how we encapsulate Session-State in a later part.

Soon – once that MVC 2 is finalized and released – we will have access to the new Html.Action command with which we can easily render partials for shared functionality, like navigation structure or other parts of the master page that need dynamic data. As Phil Haack shows in this post it’s a very powerful and urgently needed feature.

In the master view you will have a call like this:

<%= Html.Action("Menu") %>

This will directly call a method in one of your controllers to supply the partial view with its data:

[ChildActionOnly]
public ActionResult Menu() {

	NavigationData navigationData = navigationService.GetNavigationData();
	MenuViewModel menuViewModel = mapper.GetMenuViewModel(navigationData);

	return PartialView(menuViewModel);
}

Unfortunately in MVC 1 we have to make use of a more elaborate trick to get the data to the partial view.

In the earlier post about view hierarchy I showed you what our master view looks like and how partial views are included:

	<% Html.RenderPartial("Menu", ViewData.Eval("DataForMenu")); %>

The attribute

But how do we make sure the data is present in ViewData? We do this through the use of attributes. For each partial there is an attribute that puts the view data into ViewData.

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method,
				AllowMultiple = false)]
public sealed class DataForMenuAttribute : ActionFilterAttribute
{
	public override void OnActionExecuting(ActionExecutingContext filterContext)
	{
		// Work only for GET request
		if (filterContext.RequestContext.HttpContext.Request.RequestType != "GET")
			return;

		// Do not work with AjaxRequests
		if (filterContext.RequestContext.HttpContext.Request.IsAjaxRequest())
			return;

		NavigationData navigationData = navigationService.GetNavigationData();
		MenuViewModel menuViewModel = mapper.GetMenuViewModel(navigationData);

		filterContext.Controller.ViewData["DataForMenu"] = menuViewModel;
	}
}

This attribute sets the data for the partial view. As you can see from the highlighted line we don’t set data for POST requests. To make this possible we have to make sure we never render views for POST requests. We do this by upholding the Post-Redirect-Get pattern. More on that in a future part.

Of course, we have to make sure that every controller that makes use of the master view, which includes the Menu partial view, has this attribute set.

[DataForMenu]
public HomeController : Controller
{

The trouble with attributes in MVC is that you have no control over the creation of their instances. This makes it hard to use dependency injection, but not completely impossible. We have to make sure there’s a parameterless constructor for MVC to instantiate them, but we can make an overloaded constructor, that is called from the parameterless one to make use of dependency injection:

public sealed class DataForMenuAttribute : ActionFilterAttribute
{
	private readonly INavigationService navigationService;
	private readonly IViewModelMapper mapper;

	public DataForMenuAttribute() :
		this(ObjectFactory.GetInstance<INavigationService>(),
			 ObjectFactory.GetInstance<IViewModelMapper>())
	{}

	public DataForMenuAttribute(INavigationService navigationService,
								IViewModelMapper mapper)
	{
		this.navigationService = navigationService;
		this.mapper = mapper;
	}

Until now we succeeded to limit the use of StructureMap to only one line in the ControllerFactory, however attributes are the one part of MVC that makes it impossible to limit usage of ObjectFactory.GetInstance to just a single occurrence.

Unit testing the attribute

Fortunately, with the overloaded constructor in place, we are able to make use of AutoMocker for unit testing the attribute.

[TestFixture]
public class DataForMenuAttributeTests
{
	private RhinoAutoMocker<DataForMenuAttribute> autoMocker;
	private DataForMenuAttribute attribute;

	private SomeController controller;
	private ActionExecutingContext context;
	private HttpRequestBase httpRequestMock;
	private HttpContextBase httpContextMock;

	[SetUp]
	public void Setup()
	{
		StructureMapBootstrapper.Restart();

		autoMocker = new RhinoAutoMocker<DataForMenuAttribute>(MockMode.AAA);
		attribute = autoMocker.ClassUnderTest;

		controller = new SomeController();
		httpRequestMock = MockRepository.GenerateMock<HttpRequestBase>();
		httpContextMock = MockRepository.GenerateMock<HttpContextBase>();
		httpContextMock.Expect(x => x.Request).Repeat.Any().Return(httpRequestMock);

		context = new ActionExecutingContext(
					new ControllerContext(httpContextMock ,
										  new RouteData(),
										  controller),
                                        MockRepository.GenerateMock<ActionDescriptor>(),
					new Dictionary<string, object>());
	}

	[Test]
	public void DataForMenuAttributeShouldNotSetViewDataForPostRequest()
	{
		//Arrange
		httpRequestMock.Expect(r => r.RequestType).Return("POST");

		//Act
		attribute.OnActionExecuting(context);

		//Assert
		Assert.That(controller.ViewData["DataForMenu"], Is.Null);
	}

	[Test]
	public void DataForMenuAttributeShouldNotSetViewDataForAjaxRequest()
	{
		//Arrange
		httpRequestMock.Expect(r => r.RequestType).Return("GET");
		httpRequestMock.Expect(r => r["X-Requested-With"]).Return("XMLHttpRequest");

		//Act
		attribute.OnActionExecuting(context);

		//Assert
		Assert.That(controller.ViewData["DataForMenu"], Is.Null);
	}

	[Test]
	public void DataForMenuAttributeShouldCallGetNavigationData()
	{
		//Arrange
		httpRequestMock.Expect(r => r.RequestType).Return("GET");
		httpRequestMock.Expect(r => r["X-Requested-With"]).Return(string.Empty);

		NavigationData navigationData = new NavigationData();
		autoMocker.Get<INavigationService>()
			.Expect(x => x.GetNavigationData()).Return(navigationData);

		//Act
		attribute.OnActionExecuting(context);

		//Assert
		autoMocker.Get<INavigationService>().VerifyAllExpectations();
	}

	[Test]
	public void DataForMenuAttributeShouldCallGetMenuViewModel()
	{
		//Arrange
		httpRequestMock.Expect(r => r.RequestType).Return("GET");
		httpRequestMock.Expect(r => r["X-Requested-With"]).Return(string.Empty);

		NavigationData navigationData = new NavigationData();
		MenuViewModel menuViewModel = new MenuViewModel();
		autoMocker.Get<INavigationService>()
			.Expect(x => x.GetNavigationData()).Return(navigationData);
		autoMocker.Get<IViewModelMapper>()
			.Expect(x => x.GetMenuViewModel(navigationData)).Return(menuViewModel);

		//Act
		attribute.OnActionExecuting(context);

		//Assert
		autoMocker.Get<IViewModelMapper>().VerifyAllExpectations();
	}

	[Test]
	public void DataForMenuAttributeShouldSetMenuViewDataToGetMenuViewModelResult()
	{
		//Arrange
		httpRequestMock.Expect(r => r.RequestType).Return("GET");
		httpRequestMock.Expect(r => r["X-Requested-With"]).Return(string.Empty);

		MenuViewModel menuViewModel = new MenuViewModel();
		autoMocker.Get<IViewModelMapper>()
			.Expect(x => x.GetMenuViewModel(Arg<NavigationData>.Is.Anything))
			.Return(menuViewModel);

		//Act
		attribute.OnActionExecuting(context);

		//Assert
		Assert.That(controller.ViewData["DataForMenu"], Is.EqualTo(menuViewModel));
	}
}

As you can see, it’s quite a lot of work setting up expectations and especially the context for testing an attribute.

Also, notice that for each test I try to arrange and assert just what’s needed to verify that the code does what the name of the test says it should do.

Having multiple assertions in every test makes it much more difficult to alter the code under test. Ideally you would want to ditch the tests that verify functionality that’s no longer wanted and create new tests to verify new functionality.
For example, if you decide not to use the INavigationService any longer for returning data to feed to the IViewModelMapper, the DataForMenuAttributeShouldCallGetNavigationData test can be removed and DataForMenuAttributeShouldCallGetMenuViewModel has to be altered slightly.

One last thing we have to test is the presence of the attribute on the controllers where it’s necessary. This can be done in the following manner:

[Test]
public void ExampleControllerShouldHaveDataForMenuAttribute()
{
	Assert.That(Attribute.GetCustomAttribute(typeof(ExampleController),
											 typeof(DataForMenuAttribute)),
				Is.Not.Null);
}

Make sure you have this test for every controller that needs the attribute!

Concluding, as you can see by the amount of work that’s needed to test the attribute itself and its presence on the controllers, you can imagine we’re really looking forward to MVC 2′s RenderAction.

As mentioned in the previous post all views are strongly typed and every view has it’s own View Model. Although this results in quite a lot of classes the upside is maintainability in that it’s very straightforward. Every bit of data displayed in the view has a corresponding property in the View Model. As soon as it’s no longer needed in the view we remove the property as well.

Of course, it sounds like it’s in opposition with the DRY principle (Don’t Repeat Yourself). However the data in the properties of the view models stems from the domain model, meaning the business rules are still in one place. To get the data from the domain model to the view models we have mapper classes in the presentation layer.

View model mapper

A simple example of how a controller action will call the mapper to convert a domain model into a view model can be seen below:

public ActionResult ShowItem(int id)
{
	DomainModel item = repository.GetItem(id);

	ViewModel viewModel = mapper.MapToViewModel(item);

	return View("ShowItem", viewModel);
}

Inside the MapToViewModel method we can have something like the following:

public ViewModel MapToViewModel(DomainModel domainModel)
{
	ViewModel viewModel = new ViewModel
	{
		Id = domainModel.Id,
		Name = domainModel.Name,
		Description = domainModel.Description
	};

	return viewModel;
}

But wait, writing this code is a dull job and it’s easy to make a mistake. Therefore we make use of the AutoMapper library by Jimmy Bogard as much as possible.

AutoMapper

AutoMapper is a library with the purpose of mapping properties of a complex type to a simple type like a view model. It’s not meant to be used the other way around, going from a poor model to a richer model with more properties.

Besides saving you of writing lots of code it also has test facilities to warn you if your target model (the view model) has new properties which have no counterpart in the source model (the domain model). An example of how we could use AutoMapper in the MapToViewModel method:

public ViewModel MapToViewModel(DomainModel domainModel)
{
	Mapper.CreateMap<DomainModel, ViewModel>();

	ViewModel viewModel = Mapper.Map<DomainModel, ViewModel>(domainModel);

	return viewModel;
}

If ViewModel gets richer and new properties are present in DomainModel no single line of code will have to be altered in the mapper.

For testing if all properties of ViewModel (that have a setter) can be mapped by AutoMapper we move the CreateMap line to a AutoMapperBootstrapper class:

public class AutoMapperBootstrapper
{
	public void BootstrapAutoMapper()
	{
		Mapper.CreateMap<DomainModel, ViewModel>();
		Mapper.CreateMap<DomainModel, OtherViewModel>();
	}

	public static void Bootstrap()
	{
		new AutoMapperBootstrapper().BootstrapAutoMapper();
	}
}

Having this code in a separate bootstrapper instead of the mapper classes is in order to have configuration centralized and because now testing of all these mappings is very easy. Just one test suffices for all mappings:

[Test]
public void CheckIfConfigurationIsValid()
{
	AutoMapperBootstrapper.Bootstrap();

	Mapper.AssertConfigurationIsValid();
}

This test will fail as soon as there’s a property in one of the target models that can’t be mapped from the source model.

But what if our view model has to have a property that doesn’t get it’s value from the domain model? Well, we can chain some extra options to the CreateMap method to let AutoMapper ignore this property when mapping and when testing as well:

Mapper.CreateMap<DomainModel, ViewModel>()
	.ForMember(x => x.NoDomainProperty, opt => opt.Ignore());

Now we can set this property after mapping DomainModel to ViewModel:

public ViewModel MapToViewModel(DomainModel domainModel)
{
	ViewModel viewModel = Mapper.Map<DomainModel, ViewModel>(domainModel);
	viewModel.NoDomainProperty = repository.GetOtherData();

	return viewModel;
}

AutoMapper has a lot more in store like converting between types – for which you can even specify a custom converter – and other nice stuff. For more specifics visit the AutoMapper site.

Form Model

In going from the controller to the view we make use of view models. But what about going the other way? Do we post view models? No, to keep things clear we only post form models.

So are they different from view models? Not really. In code they are pretty much equal to view models, however it’s more of a convention to name all models going outwards (towards the view) a view model and all models going inwards a form model. Also we try to make sure all properties can and will be filled by posted data. So no select lists and other presentation stuff in the form model.

In the last blog post I showed you how we pass the form model to the view containing the form. It is passed as a property of the view model for the specific view containing the form:

public class ViewModel {

	public FormModel Data { get; set; }

	public string NameLabel { get; set; }

	public string DescriptionLabel { get; set; }

	public string CountryLabel { get; set; }

	public SelectList Countries { get; set; }

	public string CountryChooseOption { get; set; }

}

In the form view the data will be used like this:

<% using(Html.BeginForm()) {%>
	<%= Html.AntiForgeryToken() %>
	<label>
		<%= Html.Encode(Model.NameLabel) %>:
		<%= Html.TextArea("Name", Model.Data.Name) %>
	</label>
	<label>
		<%= Html.Encode(Model.DescriptionLabel) %>:
		<%= Html.TextArea("Description", Model.Data.Description) %>
	</label>
	<label>
		<%= Html.Encode(Model.CountryLabel) %>:
		<%= Html.DropDownList("Country", Model.Countries, Model.CountryChooseOption) %>
	</label>
	<input type="submit" value="Save">
<% } %>

As you can see the values of the input fields are populated from the form model, while representation data like the dropdown list items and labels come from the viewmodel.

Posting the form model

A bonus of having all properties correspond to a form field is that all of them will be binded automatically by MVC. No need for custom binding here.

Usage of the form model will look like this:

[AcceptVerbs(HttpVerbs.Post), ValidateAntiForgeryToken]
public ActionResult UpdateItem(int id, FormModel formModel)
{
	DomainModel item = repository.GetItem(id);

	item.Name = formModel.Name;
	item.Description = formModel.Description;

	repository.SaveItem(item);

	return RedirectToAction("UpdateItem", new{ id });
}

Of course the code above is just an example. The method will soon start to bloat if we add validation and other aspects (like setting success or error message to display on the page redirected to). So in order to keep the controller thin we’ll move the highlighted lines into a separate form handler.

Form handler

The form handler handles updating the domain model from the form model. It does checks to make sure the item to be updated belongs to the user posting the data. Etc, etc. It’s the beating heart if it comes to processing the commands coming in from the end user’s browser.

Just like in the view model mapper there is at least one method for each form model to handle either creation of a new item or updating an existing one. Or handling other commands than the usual CRUD. It fits the CQRS (Command Query Responsibility Segregation) principle nicely. View models and mapping for query’ing, form models and form handlers for command handling. More on CQRS over here.

Validation

One last thing to talk about is validation. Validation is done on multiple levels. Our form models have their own validation, to make sure the posted data is what we want in terms of being required, being numeric or being an e-mail address. No difficult validation to see if shipping an order to a certain country is allowed. This belongs in the domain, because it’s core business logic.

Another benefit of having validation on the form model is that client-side validation is done easily.

Handling the first level protection of validating the form model can be done in the controller or in the form handler. Additional levels of validation are fed back to the controller by the form handler. Probably in the form of a result object with a property indicating if handling was successful and a property with a list of failed validation and more properties if we want to be able to have a complex page flow in the site.

I’m still thinking of ways to have the (simple) validation rules of the domain model automatically being used for the form model as well. But for now we have some duplication over here, which – I know – is an issue regarding maintainability. But it isn’t very often that a field being required one day stops being required the other day. Just simple validation over here. And the domain model validation is always there to back up the form model validation.

The view system of ASP.NET MVC knows the followings types of views:

• Master views
• Page views
• Partial views

The regular page view contains the specific html and presentation of data for each rendered page. For html shared by multiple pages – like navigation, header and footer – every page has a master page.

Both of these types can include partial views for small parts, that can be reused from multiple views. For example page navigation for display of results covering multiple pages, or widgets. Even if they’re not reused it is useful to separate parts of your page view or master view to partial views, to keep the (master) view itself comprehensible and maintainable.

For using partial views in the master view we have a special way to provide them with data (which is sometimes specific to the page requested, like which menu item is active). This is explained in the future part Poor Man’s RenderAction.

Master view

In the following diagram you can see the master page and it’s partial views. A page view is shown in more detail later on.

The code for the Site.Master looks something like this:

<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>
<%@ Import Namespace="ClientX.Website.Models"%>

<!DOCTYPE html>
<html>
<head>
	<meta charset="utf-8">
	<title>Site title - <asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>
<% #if DEBUG %>
	<% Html.RenderPartial("CssDebug", ViewData.Eval("DataForCss")); %>
<% #else %>
	<% Html.RenderPartial("CssRelease", ViewData.Eval("DataForCss")); %>
<% #endif %>
</head>
<body>

	<% Html.RenderPartial("Header", ViewData.Eval("DataForHeader")); %>

	<% Html.RenderPartial("PostBackForm", ViewData.Eval("DataForPostBackForm")); %>

	<% Html.RenderPartial("Messages", ViewData.Eval("DataForMessages")); %>

	<div class="content">

		<asp:ContentPlaceHolder ID="MainContent" runat="server" />

	</div><!-- /content -->

	<% Html.RenderPartial("Footer", ViewData.Eval("DataForFooter")); %>

<% #if DEBUG %>
	<% Html.RenderPartial("JavascriptDebug", ViewData.Eval("DataForJavascript")); %>
<% #else %>
	<% Html.RenderPartial("JavascriptRelease", ViewData.Eval("DataForJavascript")); %>
<% #endif %>

</body>
</html>

In the code above you can identify the inclusion of multiple partial views and the placeholders where the page view descending from the master view can show their html. This quite straightforward.

More specific to our master is the way we select the javascript and css partial views. The DEBUG switches make sure the right css and javascript is included on the production server. For development you’ll want to use your original javascript files, while the production servers will serve minified and merged javascript files.

The data supplied to the to the partial views makes it look like these partial views aren’t strongly type, however they certainly are. Perhaps it’s possible to provide the master view itself with a strongly typed model, however the effort is probably not worth it, because production issues rarely arise within the master view.

If your site uses multiple different layouts (1, 2 or 3 columns for example) it is advisable to have nested master pages. The top one still keeps the css, javascript and navigation, where the nested master pages will only contain the html that differs between the different layouts.

Page view

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<OverviewViewModel>" %>
<%@ Import Namespace="ClientX.Website.Models"%>

<asp:Content ID="TitleContentPlaceHolder" ContentPlaceHolderID="TitleContent" runat="server">
	Page title
</asp:Content>

<asp:Content ID="MainContentPlaceHolder" ContentPlaceHolderID="MainContent" runat="server">

	<% Html.RenderPartial("Heading", Model.Heading); %>

	<div>
		<% Html.RenderPartial("OverviewSearchForm", Model.OverviewSearchForm); %>

		<% Html.RenderPartial("Pager", Model.Pager); %>

		<table>
			<% Html.RenderPartial("TableHeader", Model.TableHeader); %>
			<%foreach (TableRowViewModel item in Model.ItemList){
				Html.RenderPartial("TableRow", item);
			} %>
		</table>

		<% Html.RenderPartial("Pager", Model.Pager); %>
	</div>
</asp:Content>

The page view is a little bit different from the master view. For one, it actually contains the content for the placeholders present in the master view. The other difference with the master view is that the included partial views are called strongly-typed.

Also notice, in the first line, that the view is strongly typed. All of our page views and partial views are strongly typed, no exceptions made.

Furthermore, our rule is never (and I mean never) to share a view model between multiple views. Each view has it’s own tailor made view model.

The view model only has properties which are actually used in the view. Also, it is totally flat (only simple properties) and quite dumb. You wouldn’t want to put too much logic in the view model, because it discourages reuse of the logic in question.

To fill the view models from the domain model we use AutoMapper by Jimmy Bogard where possible and for the rest set it by hand in our presentation mapper classes. More on that in future part ViewModel and FormModel.

The only view models that aren’t completely flattened are the ones containing form data. The view model itself contains data that is just for view purposes, like select lists and descriptions for radio button options, etc. The form data itself is contained in a form model, which is accessible through the view model. Something like the code below:

public class SearchFormViewModel {

	public SearchFormModel FormData { get; set; }

	public SelectList Countries { get; set; }

	public SelectList OtherDropDownData { get; set; }

}

Okay, enough for now. More on view models and form models in the next part.

To make your code testable the pattern to use is that of Dependency Injection. DI is nothing more than injecting all dependencies of a class instance through the constructor (or setters if you wish, but less intuitive when reading the code, and doesn’t guarantee all dependencies are set). For example if you have a controller that uses a factory and a repository you can both inject them into the constructor as follows:

public class Controller
{
	private readonly IFactory factory;
	private readonly IRepository repository;

	public Controller(IFactory factory, IRepository repository)
	{
		this.factory = factory;
		this.repository = repository;
	}
}

When looking at the constructor you immediately see on which components this class depends. Using interfaces makes testing even more simple, because then we can easily mock the dependencies. Creating an instance of the controller will look as follows:

IFactory factory = new Factory();
IRepository repository = new Repository();

Controller controller = new Controller(factory, repository);

Once your nesting of dependencies gets bigger, setting up your instances becomes quite cumbersome. This causes you to rethink before you add another dependency to a class. This hinders testability, so you would really want adding another dependency to be a piece of cake.

Enters Inversion Of Control container. The IOC container is some software that handles initialization of all your dependencies. StructureMap is on of the longest available ones for .Net. Others are Castle Windsor, Spring.NET, Unity, Ninject and others. What makes StructureMap very pleasant to work with is it’s extra facilities for testing.

First an example of how you use StructureMap to initialize your instances.

To setup which classes to use for which interfaces you do the following initialization once:

ObjectFactory.Initialize(x =>
	{
		x.For<IFactory>().Use<Factory>();
		x.For<IRepository>().Use<Repository>();
	});

Then every time you need an instance of your controller you can use the following code:

Controller controller = ObjectFactory.GetInstance<Controller>();

StructureMap looks at the constructor of class Controller and sees it’s dependent on an IFactory and IRepository. It knows which concrete classes to use for these interfaces, so it creates those first and then creates the Controller instance by injecting them into the constructor.

StructureMap in MVC

In a standard MVC project your controllers are required to have a parameterless constructor, which is used to initialize them. Of course this is in conflict with the Dependency Injection we want to use the make our code testable and easy to setup with StructureMap. However MVC is extensible on this point, and we can provide our own ControllerFactory, which looks as follows:

public class StructureMapControllerFactory : DefaultControllerFactory
{
	protected override IController GetControllerInstance(Type controllerType)
	{
		if (controllerType == null)
		{
			return base.GetControllerInstance(controllerType);
		}

		try
		{
			return ObjectFactory.GetInstance(controllerType) as Controller;
		}
		catch (StructureMapException exception)
		{
			// log an error with the exception and ObjectFactory.WhatDoIHave()
			throw;
		}
	}
}

In MVC 2 the signature of method GetControllerInstance looks a little different, so our StructureMapControllerFactory will be adjusted correspondingly:

public class StructureMapControllerFactory : DefaultControllerFactory
{
	protected override IController GetControllerInstance(RequestContext requestContext,
														 Type controllerType)
	{
		if (controllerType == null)
		{
			return base.GetControllerInstance(requestContext, controllerType);
		}

		try
		{
			return ObjectFactory.GetInstance(controllerType) as Controller;
		}
		catch (StructureMapException exception)
		{
			// log an error with the exception and ObjectFactory.WhatDoIHave()
			throw;
		}
	}
}

This factory makes sure that StructureMap initializes your controllers. Now to make MVC use this factory we add the following code to the Global.asax.cs:

protected void Application_Start()
{
	// initialize structuremap container
	StructureMapBootstrapper.Bootstrap();

	// let structuremap handle creating controllers
	ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());
}

On the last line we set the factory. The first line calls the bootstrapper, which does the initialization of StructureMap.

public class StructureMapBootstrapper : IBootstrapper
{
	private static bool hasStarted;

	public void BootstrapStructureMap()
	{
		ObjectFactory.Initialize(x =>
		{
			x.For<ISessionHandler>().Use<SessionHandler>();
			x.For<ITempDataHandler>().Use<TempDataHandler>();

			x.ForSingletonOf<ICacheHandler>().Use<CacheHandler>();

			x.AddRegistry<FactoryRegistry>();
			x.AddRegistry<RepositoryRegistry>();
			x.AddRegistry<ServiceRegistry>();
		});
	}

	public static void Restart()
	{
		if (hasStarted)
		{
			ObjectFactory.ResetDefaults();
		}
		else
		{
			Bootstrap();
			hasStarted = true;
		}
	}

	public static void Bootstrap()
	{
		new StructureMapBootstrapper().BootstrapStructureMap();
	}
}

The highlighted ObjectFactory.Initialize part in the code above is the part that is custom for your project. Here you specify which concrete class to use for which interface. The initialization isn’t very fast, but only performed once in production code. For testing purposes this is to costly, so the restart action is provided.

You can also see the lines with AddRegistry: the registries that are added are a way to group your code, because otherwise the bootstrapper can become quite long. A definition of a registry:

public class FactoryRegistry : Registry
{
	public FactoryRegistry()
	{
		For<IInputModelFactory>().Use<InputModelFactory>();
		For<IViewModelFactory>().Use<ViewModelFactory>();
	}
}

The specific StructureMap code in your project only consists of the BootStrapper, the registries and the ControllerFactory. It’s best to try and avoid the use of ObjectFactory.GetInstance throughout your code as much as possible. It makes it harder to replace StructureMap if you want to, but more importantly it makes your code harder to test. One case where you’ll probably won’t manage without is in the case of attributes. The creation of attribute instances is done by MVC and needs a parameterless constructor as well. However we can’t replace the factory in this case.

Unfortunately we need an extra use of ObjectFactory.GetInstance, but we can do it within the constructor to keep it testable:

public class CustomAttribute : ActionFilterAttribute
{
	private readonly ISessionHandler sessionHandler;

	public CustomAttribute()
	: this(ObjectFactory.GetInstance<ISessionHandler>())
	{
	}

	public CustomAttribute(ISessionHandler sessionHandler)
	{
		this.sessionHandler = sessionHandler;
	}

If a class is created by StructureMap it defaults to the constructor with the most parameters.

Testing with AutoMocker

Okay, on to the reason I prefer StructureMap as an IOC container: AutoMocker. The RhinoAutoMocker creates an instance of the class under test and creates a Rhino Mock object for all (interfaced) dependencies. No more creation of mock objects yourself. And even more important you can add another dependency to a class without having to fix all tests that create an instance.

A test fixture will look as follows:

[TestFixture]
public class AdvertsControllerTests
{
	private RhinoAutoMocker<Controller> autoMocker;
	private Controller controller;

	[SetUp]
	public void Setup()
	{
		StructureMapBootstrapper.Restart();

		autoMocker = new RhinoAutoMocker<Controller>(MockMode.AAA);
		controller = autoMocker.ClassUnderTest;
	}

	[Test]
	public void CreatePostShouldCallFormHandlerForValidPost()
	{
		//Arrange
		FormEditModel editModel = new FormEditModel();
		autoMocker.Get<IFormHandler>().Expect(p => p.CreatePost(Arg<FormEditModel>.Is.Anything)).Return(true);

		//Act
		controller.CreatePost(editModel);

		//Assert
		autoMocker.Get<IFormHandler>().VerifyAllExpectations();
	}

The highlighted autoMocker.Get<IFormHandler>() lines retrieve a mock object and set expectations. So, per test you only have to set the dependencies neccessary for the code under test. A controller often has a lot of dependencies, but they’re not used by every action.

The following subjects will be handled in oncoming blogs:

• Inversion of Control container: StructureMap
• View hierarchy
• View Model and Form Model
• Poor man’s RenderAction
• Post-Redirect-Get pattern
• Binding

To make the site as testable and maintainable as possible I adhere to the DRY principle (don’t repeat yourself) and try to write SOLID code:

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion

Another aspect to focus on is to keep the controllers mean and lean. This is called the skinny controller, fat model; it states to have your controller actions as thin/short as possible, because you really want to avoid having business logic in your controller. Keeping the business logic in the domain model and service layer encourages reuse and makes it easier to update your site flow, and of course avoids having duplicate code in your project. It’s really a question of Separation Of Concerns.

Architecture

The following diagram globally represents the architecture of our MVC application. The layers are explained in a bit more detail below from bottom to top.

Infrastructure layer

Data is often accessed in databases or through web services; there usually is an impedance mismatch between their data structure and our domain model. To overcome this mismatch we have mappers to perform the conversion from data model to domain model and vice versa.

The repositories provide CRUD functionality for the domain models to the physical storage layer with the use of the mappers.

Domain layer

Inside this layer the services provide access to data in the form of domain models as well as the possibility to handle various other actions as creating and updating new objects.

The core business logic of the site is contained in this layer. This makes it reusable by all controllers and views.

Presentation layer

The controllers of course play the central role in this layer. On get requests the controller requests domain models from the services in the layer beneath and passes these to the views in the form of view models; the conversion between domain models and view models is handled by the mappers.

In the case of views containing a form, the controller supplies the view with a form model. These contain various data from the domain model. Except for the data being edited it also contains data for dropdown lists and the likes. These models are also converted in the mappers.

When data is posted it usually enters the controller action as a form model. This model is handed off to a handler that updates the domain model with the data from the form model. This prevents the possibility of security leaks through overposting or underposting. Furthermore it keeps the controller skinny. Sequentially the handler calls the services for further handling of the actions neccessary to persist any changes.

To accomplish this the crucial part of the plugin performs the following DOM manipulation:

elementToWrap.html(
	'<div class="frame" style="width: 157px;">' +
		elementToWrap.html() +
		'<div class="right_shadow">' +
			'<div class="shadow_top_right"></div>' +
			'<div class="shadow_right" style="height: 93px;"></div>' +
		'</div>' +
		'<div class="bottom_shadow">'
			'<div class="shadow_bottom_left"></div>' +
			'<div class="shadow_bottom" style="width: 143px;"></div>' +
			'<div class="shadow_bottom_right"></div>' +
		'</div>' +
	'</div>'
);

However, when I started using it in my site, page loads seemed sluggish. Especially on the thumbnail pages, with some 20 images to apply the plugin to. I was in for some performance measurements. With the Firefox plugin Firebug this is easy. You surround the code for which you want to measure the execution time with the following code:

console.time('applyShadow');
...
console.timeEnd('applyShadow')

After which the firebug console will present you with timing in milliseconds for each time the plugin wraps an image with the forementioned divs. It looks as follows on my 2,4GHz quadcore:

In total it adds up to some 100-200ms for the 20 images on my homepage and even more on other pages. I’m afraid that with current browsers – even on Google Chrome you could notice the difference – this kind of offloading html generation to the client-side isn’t performant enough. If you want to run a bleeding fast website DOM manipulation should be kept to a minimum. Of course it is still very useful and acceptable when reacting on user interactions (like with the jQuery UI dialogs).

Some very useful tips when it comes to using jQuery and performance can be found over here:

http://www.tvidesign.co.uk/blog/improve-your-jquery-25-excellent-tips.aspx