Despite not originally being intended as a S#arp Arch demo, it was adopted as one. Which gave rise to the question: what do we do with it for S#arp Arch 2.0? When we built it, we wanted to demonstrate the architecture and toolset we used for an enterprise-level e-commerce site. We didn’t go out of our way to demonstrate any specific patterns, and we made no effort to demonstrate many of the nice features offered by the different tools we used. After some back and forth between the team we decided that things have moved on in the last 2 years, and whilst we are all still proud of the e-commerce site it was based on, WCHM is not representative of the way we choose to build websites today.

In addition, those who follow Ayende’s blog may have noticed his recent code review on WCHM. He raised some valid issues with the code, and fortunately there are several upcoming SA 2.0 features that will help me address them. So here’s the hit list for how WCHM 1.9.6 will go not only to 2.0, but also to being a true Sharp Architecture sample app.

Firstly, relevant points from Ayende’s review:

The mapping sucks

The pattern we adopted when writing our controllers is as follows:

• Receive request.
• Make request to tasks layer (aka application services); get domain entities returned.
• Use mapper to map entities to view models.
• Return view result, passing view model.

This looks extremely simple on paper, and for the most part it is. However it has a few issues:

• It can get messy quickly, especially if your view requires several disparate pieces of data – in this case, the controller makes multiple calls to the tasks layer to retrieve the required data, which is then passed into a mapper. Often this mapper will use other mappers to map collections or child view models.
• It is, as Ayende pointed out, a breeding ground for SELECT N+1 issues.

S#arp Arch 2.0 has a solution to this problem in the form of the Enhanced Query Object approach. So, to populate a view model we no longer make calls into the tasks layer. Instead we use a query object which retrieves all necessary data. Because the EQO talks directly to the NHibernate session we can bypass the layers of abstraction that Ayende derides in his posts, replacing it with LINQ/Criteria/HQL/named queries/whatever else we think is the right fit for the problem.

Too many specifications

There are quite a few specifications in the domain layer. They fit nicely into two categories:

1. Specifications that just shouldn’t be there at all. This covers ProfileByIdSpecification and CategoryByIdSpecification. Simply put, these shouldn’t exist. Instead, the FindOne method on the relevent repository should be used, which simply passes through to the Session.Get<T> method.
2. Specifications that aren’t really specifications. Unfortunately, this covers the remainder of the specifications. The problem is, a specification is really intended for codifying a business rule – so an OverdueInvoiceSpecification would capture what it means for an invoice to be overdue. When you look at it in that way, it’s pretty obvious that TagByNameSpecification (for example) is not codifying any business rule and as such has no place in the domain layer.

Unfortunately this means I’ll be deleting all the existing specifications. Hopefully I’ll be able to come up with a good example or two to replace them with.

Now, onto a few of my own points:

Anaemic Domain Model

Anaemic Domain Model (Wikipedia, Fowler) normally – and in my opinion, somewhat unfairly – gets labelled as an anti-pattern. It actually made a lot of sense in the original application, because in fact there was no domain logic to speak of. However, since Sharp Arch has all the DDD terms baked in, WCHM needs to do more than pay lip service to these, so I’ll be doing my best to improve this.

No obviously identified aggregate roots

Following on from the previous point – the code in WCHM doesn’t follow the DDD practice of accessing entities via aggregate roots only, so this will be another thing to improve.

Replace existing Tasks with Commands

WCHM currently uses a traditional tasks layer, with the different methods grouped up into a few different application services – CategoryTasks, ProfileTasks, etc. As described above, the query methods will be pulled out of these tasks and moved into queries that will be homed alongside the controllers. The remaining methods will be separated into commands, which will remain in the Tasks layer.

Merge Web.Controllers and Web

As detailed in Geoff’s Introductory post in this series, we’re merging controllers back into the main web project, and renaming to Presentation.

Summary

In reading this, you might think that I’m saying WCHM is a steaming pile of something unpleasant. Nothing could be further from the truth – www.fancydressoutfitters.co.uk is a project that I’m proud to have been part of, and WCHM is an extension of that. The site has been running with no significant unplanned downtime for nearly 2 years now, from a project that went from nothing to live in just ten 2 week sprints.

However, I hate it when code I’ve written is allowed to stagnate – like most of us, I look back on code I’ve written and think about all the ways it could be better. I hope that there will never be a day when I look back on one- or two-year old code and realise I’ve learned nothing since it was written. In the meantime, I’d appreciate any feedback people have on WCHM and this post.

@jon_george1

TL;DR

We’ve moved all the SA repositories into a single GitHub organisation, separated samples into their own repositories, brought the repository structures in line with one another, and implemented a common build system shared by the solution in each repository.

Some Background

Until the end of last year, Sharp Arch consisted of two repositories. We had Sharp-Architecture, which contained SA itself and the Northwind sample app, and Sharp-Architecture-Contrib, which was pretty much what it said on the tin. The master versions of these repositories lived in Billy’s GitHub account.

When we started talking about Sharp Arch 2.0, Billy had already taken a step back from the project. Who Can Help Me? had been adopted as a second sample application (with the master version living in my GitHub account), and we had big plans for both Sharp Arch itself and the sample apps we provide for it. As a result, we made a few decisions:

• We’d bring all of the Sharp Architecture repositories under one roof so that it was obvious what was “official” Sharp Arch and what wasn’t
• We’d provide each sample app – including Northwind – in it’s own repository, rather than having a single massive repository containing SA core and all of it’s samples.
• We’d adopt a common structure for all our repositories, so that people know what to expect when getting into each one.
• We’d provide a common way of building all of the projects, so that we didn’t need something specific in each repository.

Step 1. Sharp Architecture organisation on GitHub

This was the easy bit; as you probably already know if you’re a Sharp Arch user, we’ve created a new GitHub organisation that our repositories can call home. It’s at https://github.com/sharparchitecture/ and at time of writing, contains the following repositories:

• Sharp-Architecture
  The core Sharp Arch projects. This currently has a master branch, which is the source of the current release (1.9.6), and a develop branch which contains the restructured work in progress version.
• Sharp-Architecture-Features
  An all-new, 2.0 repository containing code for the different persistence options we’re providing for Sharp Arch 2.0. Because it’s new for 2.0, the master branch of this repository contains the code that’s aligned with the develop branch in the main Sharp-Architecture repo. Apologies if this is somewhat confusing.
• Sharp-Architecture-Contrib
  As with the core repo, the master branch contains the source of the current release and the develop branch contains the Contrib project that will support SA 2.0.
• Sharp-Architecture-Build
  Common build system for the Sharp Architecture solutions – see below for more information.
• Northwind
  The original SA sample app. As before, master contains the code that goes along with the current SA release, and develop will be updated to use SA 2.0.
• Who-Can-Help-Me
  Sharp Arch’s second sample app. As before, master contains the code that goes along with the current SA release, and develop will be updated to use SA 2.0.
• Sharp-Architecture-Template
  A new kid on the block, this will eventually contain the reference project structure that is used to generate the Templify package for SA. At the moment, our Templify package is built from the Northwind sample, but we are intending to change this as part of the 2.0 release.
• Sharp-Architecture-Cookbook
  Another newbie – this is a new sample application that differs from Northwind and Who Can Help Me? in that it doesn’t intend to be a real world example of how to use SA to build an app. Instead, it will contain a series of examples of different things that can be done with SA. “Recipies” that you might find in the cookbook could include the different ways of setting up NHibernate (Automapping, Fluent and traditional HBM mapping), using SA with WCF, usage scenarios for LinqRepository and the Specification pattern and so on. Our hope is that over time, this will become the main reference for “how do I…” questions.

Step 2. Repository structure

We decided to standardise on the repository structure used in WCHM. At the top level, it contains the following folders:

• Build
  Build scripts for the project – see below for more details
• BuildSystem
  Git submodule used to pull the common build bits and pieces from Sharp-Architecture-Build.
• Common
  Contains any common files used across multiple projects. In practice, this is normally a CommonAssemblyInfo.cs file, which holds the assembly attributes shared across all projects in solution, and an AssemblyVersion.cs which is automatically updated by the build process to ensure that assemblies get a version number that matches the TeamCity build number.
• ReferencedAssemblies
  Pretty much what it sounds like – external libraries that are used by the solution. These are normally organised into subfolders for each dependency, in order to make it crystal clear which assemblies are part of which dependency – for example, the NHibernate folder contains the core NHibernate.dll, Iesi.Collections and other supporting bits.
• RequiredPackages
  Installers for anything you need to set up  locally in order to use some or all of the solution. For example, it helps to have the T4Toolbox installed to work with the T4 templates that are currently part of SA, so the installer for this is included in the RequiredPackages folder of the Sharp-Architecture repository.
• Solutions
  Home for the projects that make up the solution. As you’d expect, each project is in it’s own subfolder, and the solution file sits here as well.

As mentioned above we felt that a common structure for the repositories is important. Not only does it mean that you know what to expect when getting into each repository, it also facilitates the next major step  – the creation of a common build system for all of the projects.

Step 3. Common Build System

Up until 2.0, Sharp Arch has relied on a Nant build script for build and packaging. This has served well so far, but with the changes we’ve made in the way our repositories are structured, the time was right for a change.

The build system we now have consists of two parts:

1. A set of common MSBuild targets and tasks that encapsulate steps within the build process – for example, building a solution, running unit tests, or packaging source files. These files live in the Sharp-Architecture-Build repository, and each repository contains a submodule that pulls this into the BuildSystem folder.
2. A script that is specific to each repository and invokes the correct tasks from the common build project, with the correct parameters for the project. This script, along with some batch files that can be used to run it, exists in the Build folder of each repository.

Using this set up, and with the knowledge that each repository is structured in the same way, it’s simple to assemble the correct tasks to build and package any of the solutions from the Sharp Architecture repositories. For example, the process to build the Sharp Architecture core solution consists of the following steps:

• Clean (remove any files from the Drops folder that are about to be recreated by this build)
• Update the common assembly version number file that’s shared by all projects.
• Build the solution
• Run the MSpec unit tests
• Merge the assemblies together
• Package the assembly and source files.

If you compare this with the build process for Northwind – which, given it’s a sample app rather than the framework itself, you might expect to be somewhat different – you’ll see the following steps:

• Clean
• Update the common assembly version number file that’s shared by all projects.
• Build the solution
• Run the NUnit unit tests
• Package the assembly and source files.

Clearly the bulk of the steps are actually the same as those required by the core Sharp Arch solution, hence the reason for encapsulating each of these steps in it’s own target so that it can be easily consumed as needed.

This system does, unfortunately, add some complexity to the process of getting source from GitHub and building locally. Once you’ve done a git clone of any of the repositories, it’s then necessary to run two additional commands against your clone.

• git submodule init initialises the submodule
• git submodule update updates the submodule with the files from the correct commit of the Sharp-Architecture-Build repository.

Anything that raises the barrier to getting started with Sharp Architecture is clearly not a good thing, so we’re still looking at ways in which this process can be improved.

Once the submodule is up to date, the files in the Build subfolder can then be used to build and package the solution. These scripts are also used for our CI builds, and when used with TeamCity they ensure that the assemblies created and packaged by each build are correctly version stamped with the build number, and that the packages created by the build process are published as build artefacts.

Next steps

As we continue working towards 2.0, it’s likely that we’ll evolve what I’ve described here but it’s unlikely to change radically. We’ll probably move to using NuGet instead of the old fashioned way of pulling in external dependencies, which may affect how we use the ReferencedAssemblies folders in each repository. And we’re also not entirely happy with the additional complexity that using Git Submodules adds to the mix, so we’re still thinking of ways to improve this. In addition, we’ll be making some additions to automatically create and publish the Templify and NuGet packages for Sharp Architecture.

As always, we welcome all suggestions, feedback and pull requests so please get involved and help us make Sharp Architecture something you want to use in your projects.

@jon_george1

This is good advice, and straightforward to implement under IIS7, but can leave you with a bit of a problem – once you’ve released your site with all of your scripts and stylesheets set to expire next millenium, you can no longer edit them as you please. If you change them and release them with the same name, returning visitors to your site will not see the changes – they will use the cached version that you told them was good for another 1000 years.

Instead, if you need to change one of your files, you need to give it a new name so that clients who downloaded and cached the original version are sure to get the update when it’s deployed. This means you need to update any references to point to the new file, which has the potential to be a bit of a management nightmare.

Obviously, if you’ve only got one or two of each type of file and you’ve referenced them from a master page or similar shared component then you can handle this manually. However, if you’ve got more than that, or if you’re following the recommendation to combine and pack files, then life can get more fiddly.

On a previous project, I’ve used the Aptimize Website Accelerator, which handles all this stuff for you in an extremely slick way. However, for projects that don’t use this, I wanted to come up with a way of making the process easier.

In order to do this I decided to take advantage of ASP.NET’s internal URL rewriting feature, exposed via the HttpContext.RewritePath method. What I ended up with – which you can download from Codeplex if you’d like to give it a try – has two parts, the logic to add and remove version numbers from file names and an HttpModule to apply this logic to incoming Urls. The idea is that the code writing out links to the JS/CSS files can pass those filenames through the provider to add a version number, and the HttpModule will intercept incoming requests for those files and rewrite them to point to the correct filename.

The resourcing versioning provider

Whilst I’m not a massive fan of the ASP.NET provider model, I’ve recently been feeling the pain of using a variety of different open source projects with overlapping dependencies on different versions of the same tools. I therefore decided to use the provider model to allow me to swap out different ways of generating the version number.

The first important class here is ResourceVersioningProvider. This defines the two methods that providers need to implement.

It should be pretty obvious what they do from their names.

I’ve then got a base class,  ResourceVersioningProviderBase which contains the code that’s independent of how the version number is generated (basically the filename parsing/modifying logic as well as some caching.) This class is abstract and defines a single abstract method, GetVersionNumber(). This should return the version number that’s going to be used to make the filename unique.

The final relevent class is AssemblyBasedResourceVersioningProvider, which inherits ResourceVersioningProviderBase and implements GetVersionNumber by returning the full version number of an assembly specified in the configuration. The configuration itself looks like this:

As you can see, there’s also an attribute that controls which file extensions the provider will add version numbers to. This means that if you call “AddVersionToFileName” and pass in an a filename with a different extension, no version number will be added.

The resource versioning HttpModule

The HttpModule that forms the other half of the solution is pretty straightforward. Every incoming Url is cracked open using the Uri.Segments property, and the final segment (assumed to be the requested file name) is passed into the provider to remove the version number, if present. If the provider returns a filename that differs from the one in the request url, it is used to build a new Url that can be passed to HttpContext.RewritePath. Processed Urls are cached (regardless of whether or not they require a rewrite) to improve performance.

In Practice

The module is in use on the Who Can Help Me? app I introduced in my previous post. If you have a look at the source for the homepage, you’ll see that all the CSS, JavaScript and DotLess files have the current WhoCanHelpMe.Web assembly version number as part of their name. You can get at the Who Can Help Me? source via it’s Codeplex site to see how it’s implemented.

An Alternative Approach

Despite having written this post a month or so ago, I was only spurred into posting it by reading about this alternative approach from Karl Seguin. He’s got an interesting series going on at the moment covering ASP.NET performance – it’s well worth a read. I can see that it would be fairly straightforward to replace my AssemblyBasedResourceVersioningProvider with a FileHashBasedResourceVersioningProvider, although given that no. 1 on my to do list at the moment is learning  NHibernate, it might be a while before I get round to it!

As I mentioned above, the compiled assemblies and the source code are available from my Codeplex site. Please have a play and let me know what you think.

@jon_george1

The core dev team was mostly made up of people who’d worked with one another before. For example I first worked with James back in 2002, well before either of us joined Conchango (as it then was.) James had spent a lot of time working with Howard on Tesco Digital, and although I’d never worked with Howard directly I’d had a lot of contact with him on my previous project. We’d all previously worked with Ling (our data architect), Justin (developer, yet to create his own online presence for reasons unknown) and Naz (tester, ditto) on other projects over the previous 3 years.

On most projects, the team spends a fair amount of time up front becoming effective, and a big part of that is getting to know one another – strengths, weaknesses, the way we all communicate and so on. For us, there were only a couple of people that none of us had worked with on previous projects, and that made it simple for the team as a whole to gel really quickly. The process was simplified even further by a great project manager who knew how to make things happen without needing to control the dev team, and a business analyst who managed to take a huge amount of grief from us all about his gratuitous use of clip art in his Powerpoint presentations whilst at the same time winning the respect of the client for the speed with which he understood how they worked internally.

Also, because the team was well resourced up front, Howard and James were able to spend the time laying the appropriate foundations. James has talked about this previously, so I won’t cover it again, but suffice it to say that the time invested up front paid massive dividends later in the project.

The foundations they laid included the core software stack we would use and the tools and techniques we would adopt. They decided that the core of the site would be based on ASP.NET MVC and S#arp Architecture, which is a best practice framwork joining MVC with NHibernate. They also picked some other bits and pieces to reduce friction – things like Spark, AutoMapper and xVal – and James decided that the project would use Behaviour Driven Development as a testing approach.

When all of these things came together, one thing that stood out was how clean the resulting solution became. Core design concepts such as separation of concerns, encapsulation and dependency injection were baked in, making the code clean and easy to test. The layers of the solution were well defined and understood, meaning it was always obvious where a particular piece of code should live and it was easy to discuss the codebase between us because we were all talking the same language. The adoption of BDD finally made using a test-driven approach make sense for those like me who always found it a challenge.

As the project neared it’s end, myself, James and Howard wrote some blog posts talking about various aspects of the solution, but it became hard for all of us to pull out specific bits of code to talk about because removing them from the wider context of the solution caused them to lose their meaning. Howard suggested that we could address this – as well as giving something back to the community that gave us such great software – by putting together an app based on the same architecture and publishing the source code. We could then use it to talk around specific features or areas of the architecture, and at the same time demonstrate to the community the approach we took for the FDO site.

A couple of years back, Howard spent a few hours one evening creating an app called “Who can help me?” Originally intended to capture information about the skills and experience available within Conchango, it took him about 3 hours to put together using ASP.NET WebForms and Linq to SQL. It was the ideal application for our purpose; it has a practical application (we still use it inside EMCC) and it’s simple so the focus can be on the solution design rather than the business logic.

So, here it is: Who Can Help  Me, built using S#arp Architecture, NHibernate, Spark View Engine, xVal, AutoMapper, Castle Windsor, MSpec, RhinoMocks and PostSharp. We’ve pulled in some new bits, such as MEF and DotNetOpenAuth, hooked it up to Twitter using TweetSharp to demonstrate the pattern for external service integration, and published the whole lot on Codeplex.

The result is definitely more complex than the problem requires, but that’s ok – as I mentioned above, we specifically chose a simple application to demonstrate an enterprise level architectural approach with the hope that the focus could be on the latter. So please have a play with the live site, download the code, give it the once over and let us know what you think. We’ll be blogging about the bits we find interesting (links below), as well as tidying up the bits we’re not so keen on and we’d love to hear any feedback you have.

• Jonathan George – @jon_george1
• Howard van Rooijen – @HowardvRooijen
• James Broome – @broomej

We’ll also be using the hashtag #WCHM on Twitter when we talk about this, so keep an eye out.

@jon_george1

I’ll mainly be blogging about the things I do in my day to day job as a technical consultant. Over the past few years this has primarily been developing e-commerce sites using ASP.NET, and more recently ASP.NET MVC – have a look at FancyDressOutfitters.co.uk for the most recent result. I have a strong interest in using sound engineering practices in my projects – continuous integration, test or behaviour driven development, to name a couple – as well as using lean techniques to deliver those projects.

I always welcome feedback, so please tell me what you think of my posts by leaving a comment or via Twitter.

@jon_george1

This is the final part of a series of posts on optimisation work we carried out on my last project, www.fancydressoutfitters.co.uk – an ASP.NET MVC web site built using S#arp Architecture, NHibernate, the Spark view engine and Solr. There’s not much point starting here – please have a look at parts 1, 2, 3 and 4, as well as my post on improving YSlow scores for IIS7 sites, for the full picture.

In the posts on this series, I’ve reflected the separation of concerns inherent in ASP.NET MVC applications by talking about how we optimised each layer of the application independently. Good separation of concerns is by no means unique to applications built using the MVC pattern, but what stood out for me as I became familiar with the project was that for the first time it seemed like I hardly had to think to achieve it, because it’s so baked into the framework. I know I share this feeling with Howard and James (respectively architect and developer on the project), who’ve both talked about it in their own blogs.

The MVC pattern also makes it much easier to apply optimisations in the code. For example, it’s much easier to identify the points where caching will be effective, as the Model-View-ViewModel pattern makes it straightforward to apply a simple and highly effective caching pattern within the controllers. I know that this kind of thing isn’t limited to performance work – for example, our team security guru certainly felt that it was easier to carry out his threat modelling for this site than it would have been in a WebForms equivalent.

On the flip side, this process also brought home to me some of the dangers of using NHibernate. It’s an absolutely awesome product, and has totally converted me to the use of an ORM (be it NHib or Entity Framework). However, the relatively high learning curve and the fact that most of the setup was done before I joined the project made it easy for me to ignore what it was doing under the covers and code away against my domain objects in a state of blissful ignorance. Obviously this is not a brilliant idea, and properly getting to grips with NH it now jostling for first place on my to-do list (up against PostSharp 2 and ASP.NET MVC 2.0, amongst other things.)

My big challenge for future projects is ensuring that the optimisations I’ve talked about are baked in from the start instead of being bolted on at the end. The problem with this is that it’s not always clear where to stop. The goal of optimising the site is to get it to the point where it performs as we need it to, not to get it to the point where we can’t optimise any more. The process of optimisation is one of diminishing returns, so it’s essential to cover issues you know need to be covered and to then use testing tools to uncover any further areas to work on.

That said, in an ideal world I’d like to be able to build performance tests early and use them to benchmark pages on a regular basis. Assuming you work in short iterations, this can be done on an iteration by iteration basis, with results feeding into the plan for the next iteration. My next series of posts will be on performance and load testing, and as well as covering what we did for this project I will be looking at ways of building these processes into the core engineering practices of a project.

Was it all worth it?

I’ll be talking separately about the performance and load testing we carried out on the site prior to go live, but in order to put these posts into some context I thought it might be interesting to include some final numbers. For our soak testing, we built a load profile based on 6 user journeys through the site:

• Homepage: 20% of total concurrent user load
• Browse (Home -> Category Landing -> Category Listing -> Product): 30%
• Search (Home -> Search Results): 30%
• News (Home -> News list -> News story): 10%
• Static Pages (Home -> Static page): 5%
• Checkout (As for browse journey, then -> Add to basket -> View Basket -> Checkout): 5%

With a random think time of 8 – 12 seconds between each step of each journey, we demonstrated that each of the web servers in the farm could sustainably support 1000 concurrent users and generate 90 pages per second. Given the hardware in question, this far exceeds any project I’ve worked on recently.

In the end, we put www.fancydressoutfitters.co.uk live in the run up to Halloween, the busiest time of the year for the fancy dress industry. We did this with no late nights and enough confidence to go to the pub for a celebratory pint within the hour. It was also interesting that the majority of technical colleagues who responded to our go-live announcement commented on how fast it runs (which given the machinations of our corporate network’s internet routing is even more remarkable.) And best of all, we’ve had no major shocks since the site went live.

A final note

If you’ve read this series of posts, I hope you’ve got something out of it. I’d certainly be interested in any feedback that you might have – as always, please feel free to leave a comment or contact me on Twitter.  In addition, the EMC Consulting blog site has been nominated in the Computer Weekly IT Blog Awards 2009, under the “Corporate/Large Enterprise” category – please consider voting for us.

I’d also like to extend a final thanks to Howard for proof reading the first draft of these posts and giving me valuable feedback, as well as for actually doing a lot of the work I’ve talked about here.

@jon_george1

This is the penultimate part in a series of posts on optimisation work we carried out on my last project, www.fancydressoutfitters.co.uk – an ASP.NET MVC web site built using S#arp Architecture, NHibernate, the Spark view engine and Solr. Please also take the time to read parts 1, 2 and 3 for the full picture.

Output caching is something I’ve used extensively on previous ASP.NET WebForm projects, and I was surprised when I found out that it’s relatively immature in ASP.NET MVC. The core library contains the OutputCache filter, which does the same under the covers as the @OutputCache declaration in ASP.NET Web Forms. However, caching a full page is something that rarely suits in the current climate of dynamic and personalised websites – for example (and in common with most ecommerce websites) our site includes a summary of the user’s basket on every page. In the world of web forms, I’d use the asp:substitution control to implement donut caching, or implement fragment caching. Unfortunately neither of those options exist in the brave new world of ASP.NET MVC (if you’re a Java/Ruby/etc developer… stop sniggering, we’re catching you up )

So there are a few ways round this that I’m aware of. The first involves using the partial views to do something similar to the old style ASP.NET Fragment Caching approach. In the WebForms world, this is implemented by splitting your page up into multiple user controls, and applying output caching as appropriate to the individual controls. Here’s a pretty basic example of how a product page on an ecommerce website might be laid out.

The boxes coloured blue, green and purple can all be cached – albeit with different cache lifetimes and keys. The red box, which displays my user  basket total is unlikely to be cachable – at least not at the rendering level. Using the classic ASP.NET fragment caching approach, each of my coloured boxes would be implemented as a separate user control with appropriate OutputCache directives set. The ASPX page itself would contain very little other than the instances of these controls.

So how does this translate into MVC? It turns out that it’s pretty much the same. You create a number of partial views and add an OutputCache directive to their markup. Phil Haack covers the approach in this blog post. There’s just one downside: that approach only works with the standard WebForms view engine, and we’re using Spark, so we can’t go down this route.

I did hear a suggestion that making use of the RenderAction method from ASP.NET MVC 1.0 Futures could be the way forward. Essentially, each of my coloured boxes from the diagram would end up corresponding to a separate controller action, each of which would have an OutputCache action filter applied. These would then be pulled together by a “dumb” controller action whose corresponding view had multiple calls to Html.RenderAction to compose the chunks of the view together.

On the face of it – and assuming you were willing to accept the overhead involved in repeatedly invoking the full MVC request pipeline – it would work. However, there has been mention of a bug with MVC 1.0 which causes the OutputCache filter on an action method called with RenderAction to be applied to the overall request, not just the chunk being dealt with. This kind of thing is probably why the RenderAction method was bumped into MVC Futures instead of being shipped as part of the core MVC 1.0 release.

Phil Haack blogged something else that didn’t quite make it to MVC 1.0 which looked good on the surface. Essentially, it’s an HtmlHelper extension that hooks into the API used by the asp:substitution control. However, I had a bit of a headache in trying to work out how to use it. The problem is that within the callback you supply to the Substitute method, you don’t have access to your ViewData – not a massive surprised once you understand how the post-cache substitution mechanism in ASP.NET works. This means that you need to code some other method – which is going to be a static method you’ve stashed alongside your controllers – that will do all the necessary work, pulling bits of data out of the supplied HttpContext and returning a string to be dumped directly into the view.

There’s no doubt that this would work, and with some thought could be done without losing the testability and separation of concerns that makes the MVC pattern great. However, it’s not an ideal approach for me because it does mean that the pattern and conventions are broken to support what’s essentially an optimisation step. Because of this it will make it harder for people to see what’s going on in the code. I’ve already covered the caching we applied in the service layer; to me, output caching should be contained within the View Engine layer and should not leak beyond that. After all, there’s nothing else in my controller layer or below that couples my code to Spark, so I have no desire to introduce something that does.

Fortunately it turns out that the 1.1 version of the Spark view engine will contain pretty comprehensive output caching. This isn’t part of the v1.0 release, but has been in the development builds for several months now and is stable. It’s absolutely perfect for what I wanted as it allowed me to implement output caching with very few changes outside the views.

Unlike the ASP.NET WebForms fragment caching approach, you aren’t required to split your view into partials – you simply add <cache> elements around the sections of the page you want to cache. These sections can be dependent on different keys and cached for different durations, and there’s also a signalling mechanism that allows cached content to be expired on demand. In our case, we had already tackled the issue of cache keys for a ViewModels when we looked at caching in the controller layer, so it was a simple matter to use these same cache keys to control our output caching.

Spark also contains something called the ValueHolder which effectively allows you to defer the gathering of model data until it’s needed. This means that rather than build up the model for every request, only to pass it to a view which doesn’t need it because it’s entirely output cached, you can build your model using ValueHolder objects containing lambda functions that will only be executed if the data is needed. This seems like an interesting approach, but it’s not one I explored in detail because the caching we’d already implemented on the controllers made it less relevant.

One of my major hopes, which was unfortunately not realised, was that we’d be able to connect Spark’s output caching service to our distributed cache, Velocity. This would further reduce the workload across the web farm because it would mean that once a page was served from one webhead, it would be available pre-built to all of the others. However the output caching mechanism in Spark places unserializable objects into the cache, making it difficult to use with an out-of-process caching mechanism. This is a shame but by no means a deal breaker.

I’ve seen a few discussions around the value of output caching in the MVC world, with some saying that because the views are essentially just writing text to a stream, there is little gain to be had from caching. On a purely subjective level, the output caching did seem to make the site faster. It’s difficult to be sure because there is no way of enabling/disabling output caching via config in Spark, so it’s not easy to do comparative tests in a realistic environment. I can see the argument, and I’d certainly agree that out of the different focus areas output caching made the least difference to overall performance, but I believe it did make a difference and for the minimal effort involved in implementing it, was worth it.

In the final section, I’ll talk about my views on optimising this MVC based site compared to my experiences in the WebForms world, and share some hard numbers gained from our performance testing.

@jon_george1

As I’ve previously mentioned, we’re using Microsoft Velocity as the caching provider on my current project. One of my recent tasks was to create a new implementation of ITempDataProvider that stored data in the Velocity cache instead of Session State.

Now, I’m aware that a potentially faster implementation would have been to use the Velocity Session State provider, but when I tried this I hit a few snags. Basically, when you use Velocity directly, objects you add to the cache are serialized using the DataContractSerializer from the System.Runtime.Serialization namespace. This is nice because it means you don’t need to mark all your objects with the Serializable attribute, or start implementing ISerializable – as described here, the DataContractSerializer is capable of serializing objects of any public type that has a parameterless constructor. However, when you use Velocity’s session state provider, the framework takes over and you uses the more restrictive BinaryFormatter from the System.Runtime.Serialization.Formatters.Binary namespace. This does require you to explicitly make your objects serializable, which is a bit of a pain.

To avoid going through and marking the relevant classes serializable, I took the plunge and knocked up an ITempDataProvider implementation using Velocity for my project. It was actually a very straightforward task, but once I’d done that my next issue was to work out how to get it into my controllers.

The examples I’ve seen online suggest one of two approaches:

1. Initialise it in either the constructor or the Initialize() method of the base controller.
2. Set it in the controller factory.

Option 1 would look something like this:

Simple enough, however all my controllers would instantly be tightly coupled to the VelocityTempDataProvider. Ok, so in my tests I could set the TempDataProvider property to a mock straight after creation of the controller, but it’s still not nice.

I could do this:

Which would also work, although it would require all derived controllers to pass the required instance of ITempDataProvider through from their own constructors, requiring me to modify all of the derived classes. Or there’s this:

Which will default all controllers to use the Velocity temp data provider unless they specify an alternative.

Ultimately though, I don’t like the fact that Option 1 requires selecting the correct ITempDataProvider implementation in the controllers themselves. All of these methods would work, but setting the TempDataProvider property is a responsibility that fits better in the controller factory than the controller itself. The factory is responsible for building the controller; it should be responsible for setting up any dependencies at the same time.

We’re using the WindsorControllerFactory from MvcContrib to allow Castle Windsor to create our controllers and automagically resolve their dependencies for us. As part of our application startup, we execute this code:

This is what tells the MVC framework to use the Windsor controller factory. So what’s the best way of getting my custom temp data provider in there? I could subclass the WindsorControllerFactory and override the relevant methods. But using a custom temp data provider isn’t something I’d only ever want to do with WindsorControllerFactory – it could equally apply to the default controller factory, or to any other.

It’s a scenario that could be custom made for what I think is my favourite Gang of Four design pattern: decorator. This pattern allows you to compose additional responsibilities onto an object without needing to subclass it. If you’re not familiar with it, I’d suggest a read of this chapter from the Head First Design Patterns book.

Here’s what my decorator looks like:

And here’s how it’s used:

So now all my controllers will have their TempDataProvider property set at the time of creation. As an added bonus, the specific implementation of ITempDataProvider to use is also resolved using the Windsor container making it easily configurable.

I’m a lot happier with the design I’ve ended up with – it’s more flexible and reusable and it doesn’t annoy me every time I see it. Of course, any of the other methods I mentioned would have worked, and other people might prefer them, but I hope this has given you a few options to consider if you need to do something similar.

Update (later that same day…)

Writing this up must have re-awoken some thought processes because as I was making my way home I started wondering again about my final solution. My thought process went something like this:

1. I created a decorator with the sole purpose of setting a property of my controllers. Basically, it’s job is to inject a dependency into a newly created object.
2. I am using a dependency injection tool (Castle Windsor) to create my controllers.
3. Why am I not using my dependency injection tool to inject my dependency?

Why indeed?

Ever since I started using Windsor, I’ve used constructor injection for dependencies – that way you don’t have to tell it which dependencies you need it to resolve, it will just do it’s best to satisfy all the constructor arguments from the types it has registered. But like all good IoC containers, Windsor also supports property setter injection – essentially, I can tell it to set properties on newly created objects to whatever I want them set to. (See this article for more details.)

So the decorator I was happy with last week is now redundant. That doesn’t mean it wouldn’t ever be useful – it could easily be used with the standard ASP.NET MVC controller factory, for example. However, for any controller factory that uses an IOC container it is probably not needed.

@jon_george1

This is part 3 in a series of posts on optimisation work we carried out on my current project, www.fancydressoutfitters.co.uk – an ASP.NET MVC web site built using S#arp Architecture, NHibernate, the Spark view engine and Solr. Please see  part 1 and part 2 for the background.

I doubt many people will disagree with me when I say that one sure-fire way of making a piece of code run faster and consume less of your precious processing power is to do less work in that piece of code. Optimising your code is part of the answer, but however quickly your pages run when it’s just you on the site you will struggle to serve large numbers of users unless you have a good caching strategy in place.

There are a number of places that caching can be applied in an application built using S#arp Architecture. Here are a few:

• You can use the NHibernate second-level cache to store the results of database queries.
• You can apply caching wherever it’s appropriate in your model layer.
• You can cache the results of controller actions; and
• You can apply output caching to the rendered views (to be covered in part 4).

However the whole thing is something of a balancing act. You have to understand how often things are going change and weigh up the benefits of longer caching durations against the need to reflect updates in a timely fashion. You need to understand how your platform architecture affects your caching strategy – for example, what happens if you have multiple web servers each maintaining it’s own local cache? You also need to make sure that once you’ve decided on an approach, people stick to it. I’ve never been a big fan of using the standard HTTP Cache directly – it requires you to specify the caching interval every time you add an object to the cache. Even if you implement some constants to hold the intervals, you still run the risk of people choosing the wrong one.

How we approach caching

Both my current S#arp Architecture-based project and my previous WebForms one make extensive use of Dependency Injection to decouple our assemblies and increase testability. It follows that we needed to create an abstraction for the cache anyway, so we took the opportunity to kill two birds with one stone and introduce a more convention-based approach to the cache. James has recently blogged about the benefits of removing decisions from our day-to-day coding activities, and this is another example. In our abstraction, we treat the cache as a set of named areas and assign cache duration to those areas instead of to the individual objects. A few examples of the named areas we use are:

• Content – medium lifespan, intended for content pulled from the CMS;
• Resources – very long lifespan, containing values from our SQL-based resource provider (used instead of the standard RESX file-based provider); and
• Site Furniture – long lifespan, containing less frequently changing data used in the site header and footer.

(Note: If this approach interests you at all, let me know – the specifics of the interface and implementation are two much detail to include here, but I can cover them in a separate post if there is interest.)

A nice bonus from using this abstraction on the current project was that it allowed us to use the current CTP of Velocity, Microsoft’s new distributed cache. The abstraction – together with our use of the Windsor IoC container – provided us with a handy safety net: if at any point we found an issue with using Velocity, switching back to the standard HTTP cache would be a simple configuration change. As I’ll cover in a future post our soak testing showed that Velocity is fast and stable, but even post go-live, it would still be a simple matter to make the switch if necessary. One of the tenets of lean development is that you should delay decision making until the last responsible moment – for us, the last responsible moment for deciding on a caching solution could be deferred until go-live, by which point we’d been using Velocity for around 5 months.

Applying caching in the controllers

Our first area of focus was to look at caching the results of controller actions. One of the great things about ASP.NET MVC is that things are so much simpler than in the web forms world (check this out for a pretty picture of the request handling pipeline). It’s far easier to understand where you do and don’t need to apply caching in your application code, and we realised that the most effective thing to do was to put the majority of ours in the controllers.

Howard posted a diagram of our architecture on his recent blog post about AutoMapper. From this you might be able to infer that our controllers tend to follow a pretty simple pattern:

1. Input view model is populated from request data by a model binder.
2. Input view model is mapped to domain objects.
3. Application services layer is used to do work with those domain objects.
4. Resulting domain objects are translated back into a view model that can be passed to the view.
5. Appropriate ActionResult is returned.

This is the most complex scenario – not all steps are required for every action.

In an ideal world we’d be caching the ActionResults returned by the controllers but this isn’t something we can do because they aren’t serializable and therefore can’t be cached in Velocity. We therefore have to settle for caching the ViewModel for each action, which gives us this pattern:

The [Cached] attribute is actually a PostSharp aspect that caches the result of the method call, and I have both good intentions and half finished blog posts on this subject.

If the action method takes parameters, these are passed straight through to the ActionInner method – we do the minimum amount of work possible in the action method itself.

Dealing with changing content in the CMS

In an ideal world, we would set most of the caches to have an extremely long life, then implement a mechanism to allow individual caches to be flushed as and when required. Anyone who has ever used Microsoft Commerce Server will be familiar with the SiteCacheRefresh handler which allows caches to be cleared in response to a web request. However we encountered an issue here: the current release of Velocity (CTP3), does not support enumeration or flushing of named caches – these operations are limited to cache regions. The downside with cache regions is that they are tied to a single server, which pretty much removes the benefits of using a distributed cache.

As I’ve previously mentioned, our system uses N2 for Content Management and the majority of our pages are represented in the CMS. We therefore cached the ViewModel for each page using a key based on the unique ID of the page and the last updated date of the page. This works well because it means that pages can be cached indefinitely, but as soon as someone makes a change to the page then a new version will be created and cached. Obviously this means that the old version will be lingering in the background – the downside to this approach is that you may well fill up the cache more quickly and require Velocity to evict more frequently.

This approach isn’t perfect – it doesn’t cover the product pages, and doesn’t take care of changes in the site hierarchy that would mean we need to regenerate the navigation.  As a result, we’ve implemented an additional hack: all cache keys used for content pages include the last updated time of a single page within the site. Touching that page will cause every cache key used at the controller level to change. I don’t particularly like it, but it does work.

The longer term plan would be to look at this again as and when Velocity moves on. With any luck, the next CTP (now overdue) will make some changes in this area. The ideal plan would be to:

• Hook into N2’s persistence mechanism – from reading the documentation and looking at the code, it should be possible to receive a notification when things change.  This could then be used to remove stale objects from the cache, or flush an entire named area as required.
• Implement a restricted controller that allows clearing of individual caches (in the style of the CS SiteCacheRefresh handler mentioned above.) This would be useful if we needed to clear a cache in response to an external action – such as an ETL process pulling data from a back office system.

Caching elsewhere in the application

Once we’d implemented the caching in the controllers and configured the NHibernate second-level cache in both our custom code and N2, there were very few places in our model layer that we needed to apply caching. Once again we hit the point of diminishing returns – we could spend time profiling the application and identifying any remaining bottlenecks, or we could move on and look at what we expected to be the final big win: output caching, which I’ll be talking about in the next post of this series.

A final word about caching

On a lot of projects I’ve worked on, caching is something that tends to be implemented at the end. There are advantages to this – it can help to avoid premature optimisation, and you will (hopefully) have a good understanding of the moving parts in your codebase. However, there is one major downside that anyone who’s done this will be familiar with: once you check in the changes, every single bug that is raised for the application will be blamed on your caching. Accept it, live with it, and be prepared to be known as a) grumpy, and b) easy to wind up. Just take satisfaction in the knowledge that when you get it right, you will be setting yourself up for success when you finally put your site live.

As always, I’d appreciate feedback on these posts – either by leaving a comment, dropping me an email or via Twitter.

@jon_george1

This is part 2 in a series of posts on optimisation work we carried out on my current project – an ASP.NET MVC web site built using S#arp Architecture, NHibernate, the Spark view engine and Solr. Please see “Optimising an ASP.NET MVC web site part 1 – Introduction” for the background.

Whilst there are many different things you can do to a web application to kill performance, having a badly implemented database – or a well implemented database that you access in a bad way – has got to be right up there with the best. We therefore made the database our first port of call, and started off with a pretty simple approach – fire up  SQL Server Profiler, start a new trace and see what the pain points are in each database.

Using SQL Server Profiler to find data access mistakes

As I mentioned in the introduction, the goal of our optimisation wasn’t to do everything, just to get the main things we thought were causing problems before we began our load testing. If you use the TSQL_Duration template in SQL Profiler for your trace, you can hit your site and quickly see what the most expensive queries are.

The screenshot above shows the results of repeatedly executing three different stored procedures in a random order. As you can see, the results are organised in ascending order of cost, with the interesting column being “Duration” – which shows the execution time in milliseonds.

When Howard first ran this against some of our landing and search result pages he quickly noticed a large nugget of smelliness at the bottom of the list, in the form of repeated calls to a stored procedure that was taking a whopping 400ms to execute. Whilst 400ms is not a long time – I’m sure it’s taken longer than that for you to read this sentence so far – when you call it 20 times you’ve suddenly spent 8 seconds just on database calls before any other page activity.

Digging into this identified three separate, but related issues.

1. One of our NHibernate mappings included a view based on a recursive query

Of course, this was something we’d told NHibernate to do. Our entities are organised hierarchically, and an entity can appear in multiple positions in the hierarchy. When we pass entity data to Solr for indexing, we work out the full list of paths for an entity and pass that through (see item 3 for more details.) This was done by creating a CTE to generate the list of hierarchy paths for each entity.

For the uninitiated, a Common Table Expression (or CTE) is a T-SQL construct that (amongst other things) enables you to execute recursive queries. They are very handy when dealing with hierarchical datasets, but aren’t the most efficient queries you can execute. Some time after the initial creation of the view, we’d realised that it would be useful to have the data it contained as part of our entity so we added a mapping into our NHibernate configuration. This meant that accessing that data would cause NHibernate to go off and execute a SELECT statement which included a join from the main entity table to the view. This query took in the region of 400ms.

We have two main types of page on the site landing pages and search/browse pages. The landing pages were causing this query to be executed 13 times and the browse pages were causing it to be executed 20 times, so it’s no wonder that performance had dropped. Whilst the view was never intended for use in this way, the requirement to have the data as part of our entity was still valid.

The simple solution to the problem was essentially to materialize the view. SQL Server can do this by turning the view into an indexed view – adding a unique clustered index to it does this. However, this approach isn’t applicable when the SELECT statement for the view uses a CTE, so we went with a more basic approach – since our product catalogue is actually managed in the back office and populated via ETL, we replaced the view with a table (complete with all the appropriate indexes) and tweaked the ETL to populate this table at the same time as all the rest.

For the pages in question, load time dropped from around 8 seconds to under 2, at which point we all got quite excited. However, this wasn’t solely to do with the materialisation of the view, as the investigation also showed up that…

2. Everything was being lazy loaded

By default, NHibernate uses lazy loading across the board. Depending on your object model and how it is used, this can lead to massive inefficiences. The classic example is the "SELECT N+1” anti-pattern, in which you retrieve an entity from a repository then iterate over a collection on that entity. If you’ve left NHibernate lazy loading the values, then this results in a SELECT statement being issued for every iteration of the loop. Have a look at this page on the NHibernate Profiler site for more information.

Howard spent some time using the NHibernate profiler to better understand what our app was doing, and made a number of tweaks to our mapping configuration to apply eager loading where it made sense. This provided another significant improvement, dramatically reducing the number of database calls made by the application.

3. An architectural rule imposed for performance reasons had been broken

We’d made an architectural decision to drive the search and browse functions on our website exclusively from Solr. We did this because it gives us more options for scalability. Since all the data in question comes from a single database, pulling the data directly out of that database would mean that as website load increases then so does the load on the database. The problem with that is that it’s difficult to scale a single database out – you can throw CPUs and RAM at your database server, but you’re always going to hit a limit, at which point you face some architectural challenges. This kind of basic architecture is shown in the following diagram:

Even though the main entity database is static, meaning that it would be possible to have a number of replicas of this database (potentially even one per webhead), this would require architectural change and would bring with it a new set of issues around data consistency. By pushing that load onto Solr, which has a far more straightforward scale-out story, we can grow far further without requiring a redesign. Solr basically stores a flat set of data in a form optimised for searching, and provides access via a web service. This means it is straightforward to have multiple instances of Solr running behind a load balancer. Solr makes this kind of setup even easier, as it supports a master-slave configuration as shown in the following diagram (I apologise now for the proliferation of connecting lines – I’m more of a reluctant architect than a Powerpoint architect):

In this example, the web tier will still talk direct to the data tier for some tasks – it’s unavoidable. However, we introduce the search tier which consists of a set of load balanced search servers, each of which contains an identical copy of the search index. In order to build that index, we push data from the database into the Solr master server, and the Solr master server indexes it and pushes the result out to each slave. If you can see past the nasty mess of lines, it should be obvious that as load grows, adding more webheads and/or Solr slaves is a relatively trivial operation.

However, you can have the best intentions in the world when you design your solution, but if you then go on to break the rules then it’s not going to happen. In our case, the code had ended up in a state where for each result retrieved from a Solr search, a database query would be made. Not only that, but the query in question was the horribly expensive one I mentioned in point 1.

This will no doubt cause some brow-wrinkling activity if you’re paying attention, as I mentioned that the original intended purpose of the view being used for the expensive query was to push data into Solr – so why, if the data was already in there, would we be accessing it again from the database once we’d pulled it out of Solr?

I can think of a number of good explanations, the best of which might be “My name’s Jon, and I’m a terrible programmer”. The day I get it right 100% of the time is quite probably the day I get to decide which of my Ferrari’s I drive to work, as well as the day that my projects no longer require testers, and I doubt that will ever happen. Maybe I just missed the Ballmer Peak on that day, but whatever happened, I’m just happy when the mistakes I make are as easy to identify and fix as this one was.

Using the SQL Server Database Engine Tuning Advisor

In tandem with this, we also made use of the SQL Server Database Engine Tuning Advisor. This is the next stage of evolution for the Index Tuning Wizard that (I believe) first appeared in SQL Server 2000. The MSDN page for it is here; the short (aka .NET developer) version is that you put a trace file into one end, and out of the other comes a variety of changes you can make to your database to make it go faster.

In order to generate the input, you use SQL Server Profiler with the “Tuning” template. Once this is running, and saving the trace to a file, you need to generate a “typical” load against your application. There are various ways to do this, ranging from fully manual to fully automated. We were fortunate on our project that we had a complete set of Selenium tests for the site and a way of running them as part of the build. I’m hoping that Tom, the consultant responsible for this, will start blogging about it at some point as it’s really interesting stuff. It meant that to generate our trace, all we had to do was start the profiler, kick of the test suite and go for a beer. The next morning, we pushed the resultant file through the tuning advisor and received our recommendations out of the other end. There was little we disagreed with, and most of the recommendations were subsequently applied to the database.

The rest?

You may have noticed that the main focus in this post has been around the way the application accessed the data, rather than the way the database was built. Over the duration of the project, and in addition to the fantastic data architect we had in the team, we’ve had guest appearances by JRJ, Jamie and Simon, so it shouldn’t come as a massive surprise that the database works well. EMC Consulting is rightly proud of the database guys we have on the team and whilst I’m sure that there are many further tweaks that could be made to our databases to add further go-faster stripes, they aren’t needed at the moment.  Optimisation is one of many things that doesn’t benefit by having the word “premature” put in front of it – it’s basically another form of  YAGNI. So, until testing proved otherwise, we were happy to stop at this point and move on to something else.

In the next exciting epsiode of “Optimising an ASP.NET MVC web site”, we look at a pattern for applying application layer caching. Don’t touch that dial!

Please let me know what you think of my blog posts, either by commenting, dropping me an email, or via Twitter.

@jon_george1