ploeh blog - Dependency Injection

Don’t call the container; it’ll call you

Mark Seemann — Mon, 30 Aug 2010 20:06:58 GMT

There still seems to be some confusion about what is Dependency Injection (DI) and what is a DI Container, so in this post I will try to sort it out as explicitly as possible.

DI is a set of principles and patterns that enable loose coupling.

That’s it; nothing else. Remember that old quote from p. 18 of Design Patterns?

Program to an interface; not an implementation.

This is the concern that DI addresses. The most useful DI pattern is Constructor Injection where we inject dependencies into consumers via their constructors. No container is required to do this.

The easiest way to build a DI-friendly application is to just use Constructor Injection all the way. Conversely, an application does not automatically become loosely coupled when we use a DI Container. Every time application code queries a container we have an instance of the Service Locator anti-pattern. The corollary leads to this variation of the Hollywood Principle:

Don’t call the container; it’ll call you.

A DI Container is a fantastic tool. It’s like a (motorized) mixer: you can whip cream by hand, but it’s easier with a mixer. On the other hand, without the cream the mixer is nothing. The same is true for a DI Container: to really be valuable, your code must employ Constructor Injection so that the container can auto-wire dependencies.

A well-designed application adheres to the Hollywood Principle for DI Containers: it doesn’t call the container. On the other hand, we can use the container to compose the application – or we can do it the hard way; this is called Poor Man’s DI. Here’s an example that uses Poor Man’s DI to compose a complete application graph in a console application:

private static void Main(string[]
args)

    var msgWriter
= new ConsoleMessageWriter();

    new CoalescingParserSelector(

        new IParser[]

            new HelpParser(msgWriter),

            new WineInformationParser(

                new SqlWineRepository(),

                msgWriter)

})

        .Parse(args)

        .CreateCommand()

        .Execute();

Notice how the nested structure of all the dependencies gives you an almost visual idea about the graph. What we have here is Constructor Injection all the way in.

CoalescingParserSelector’s constructor takes an IEnumerable<IParser> as input. Both HelpParser and WineInformationParser requires an IMessageWriter, and WineInformationParser also an IWineRepository. We even pull in types from different assemblies because SqlWineRepository is defined in the SQL Server-based data access assembly.

Another thing to notice is that the msgWriter variable is shared among two consumers. This is what a DI Container normally addresses with its ability to manage component lifetime. Although there’s not a DI Container in sight, we could certainly benefit from one. Let’s try to wire up the same graph using Unity (just for kicks):

private static void Main(string[]
args)

    var container
= new UnityContainer();

    container.RegisterType<IParser, WineInformationParser>("parser.info");

    container.RegisterType<IParser, HelpParser>("parser.help");

    container.RegisterType<IEnumerable<IParser>, IParser[]>();

    container.RegisterType<IParseService, CoalescingParserSelector>();

    container.RegisterType<IWineRepository, SqlWineRepository>();

    container.RegisterType<IMessageWriter, ConsoleMessageWriter>(

        new ContainerControlledLifetimeManager());

    container.Resolve<IParseService>()

        .Parse(args)

        .CreateCommand()

        .Execute();

    container.Dispose();

We are using Constructor Injection throughout, and most DI Containers (even Unity, but not MEF) natively understands that pattern. Consequently, this means that we can mostly just map interfaces to concrete types and the container will figure out the rest for us.

Notice that I’m using the Configure-Resolve-Release pattern described by Krzysztof Koźmic. First I configure the container, then I resolve the entire object graph, and lastly I dispose the container.

The main part of the application’s execution time will be spent within the Execute method, which is where all the real application code runs.

In this example I wire up a console application, but it just as well might be any other type of application. In a web application we just do a resolve per web request instead.

But wait! does that mean that we have to resolve the entire object graph of the application, even if we have dependencies that cannot be resolved at run-time? No, but that does not mean that you should pull from the container. Pull from an Abstract Factory instead.

Another question that is likely to arise is: what if I have dependencies that I rarely use? Must I wire these prematurely, even if they are expensive? No, you don’t have to do that either.

In conclusion: there is never any reason to query the container. Use a container to compose your object graph, but don’t rely on it by querying from it. Constructor Injection all the way enables most containers to auto-wire your application, and an Abstract Factory can be a dependency too.

StructureMap PerRequest vs. Unique lifetimes

Mark Seemann — Tue, 20 Jul 2010 20:42:53 GMT

StructureMap offers several different lifetimes, among these two known as PerRequest and Unique respectively. Recently I found myself wondering what was the difference between those two, but a little help from Jeremy Miller put me on the right track.

In short, Unique is equivalent to what Castle Windsor calls Transient: every time an instance of a type is needed, a new instance is created. Even if we need the same service multiple times in the same resolved graph, multiple instances are created.

PerRequest, on the other hand, is a bit special. Each type can be viewed as a Singleton within a single call to GetInstance, but as Transient across different invocations of GetInstance. In other words, the same instance will be shared within a resolved object graph, but if we resolve the same root type once more, we will get a new shared instance – a Singleton local to that graph.

Here are some unit tests I wrote to verify this behavior (recall that PerRequest is StructureMap’s default lifestyle):

[Fact]

public void ResolveServicesWithSameUniqueDependency()

    var container
= new Container();

    container.Configure(x =>

        var unique
= new UniquePerRequestLifecycle();

        x.For<IIngredient>().LifecycleIs(unique)

            .Use<Shrimp>();

        x.For<OliveOil>().LifecycleIs(unique);

        x.For<EggYolk>().LifecycleIs(unique);

        x.For<Vinegar>().LifecycleIs(unique);

        x.For<IIngredient>().LifecycleIs(unique)

            .Use<Vinaigrette>();

        x.For<IIngredient>().LifecycleIs(unique)

            .Use<Mayonnaise>();

        x.For<Course>().LifecycleIs(unique);

});

    var c1
= container.GetInstance<Course>();

    var c2
= container.GetInstance<Course>();

    Assert.NotSame(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c1.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.NotSame(

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.NotSame(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil);

[Fact]

public void ResolveServicesWithSamePerRequestDependency()

    var container
= new Container();

    container.Configure(x =>

        x.For<IIngredient>().Use<Shrimp>();

        x.For<OliveOil>();

        x.For<EggYolk>();

        x.For<Vinegar>();

        x.For<IIngredient>().Use<Vinaigrette>();

        x.For<IIngredient>().Use<Mayonnaise>();

});

    var c1
= container.GetInstance<Course>();

    var c2
= container.GetInstance<Course>();

    Assert.Same(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c1.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.Same(

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.NotSame(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil);

Notice that in both cases, the OliveOil instances are different across two independently resolved graphs (c1 and c2).

However, within each graph, the same OliveOil instance is shared in the PerRequest configuration, whereas they are different in the Unique configuration.

Upcoming talks spring 2010

Mark Seemann — Sun, 23 May 2010 16:11:37 GMT

In the next couple of weeks I will be giving a couple of talks in Copenhagen.

At Community Day 2010 I will be giving two talks on respectively Dependency Injection and TDD.

In early June I will be giving a repeat of my previous CNUG TDD talk.

Sneak view at Castle’s WCF Facility

Mark Seemann — Tue, 18 May 2010 05:27:56 GMT

One of Castle Windsor’s facilities addresses wiring up of WCF services. So far, the sparse documentation for the WCF Facility seems to indicate that you have to configure your container in a global.asax. That’s not much to my liking. First of all, it reeks of ASP.NET, and secondly, it’s not going to work if you expose WCF over protocols other than HTTP.

However, now that we know that a custom ServiceHostFactory is effectively a Singleton, a much better alternative is to derive from the WCF Facility’s DefaultServiceHost class:

public class FooServiceHostFactory :

    DefaultServiceHostFactory

    public FooServiceHostFactory()

        : base(FooServiceHostFactory.CreateKernel())

    private static IKernel CreateKernel()

        var container
= new WindsorContainer();

        container.AddFacility<WcfFacility>();

        container.Register(Component

            .For<FooService>()

            .LifeStyle.Transient);

        container.Register(Component

            .For<IBar>()

            .ImplementedBy<Bar>());

        return container.Kernel;

Although it feels a little odd to create a container and then not really use it, but only its Kernel property, this works like a charm. It correctly wires up this FooService:

public class FooService : IFooService

    private readonly IBar bar;

    public FooService(IBar bar)

        if (bar
== null)

            throw new ArgumentNullException("bar");

        this.bar
= bar;

   
#region IFooService Members

    public string Foo()

        return this.bar.Baz;

   
#endregion

However, instead of the static CreateKernel method that creates the IKernel instance, I suggest that the WCF Facility utilizes the Factory Method pattern. As the WCF Facility has not yet been released, perhaps there’s still time for that change.

In any case, the WCF Facility saves you from writing a lot of infrastructure code if you would like to wire your WCF services with Castle Windsor.

ServiceHostFactory lifetime

Mark Seemann — Mon, 17 May 2010 05:42:33 GMT

For a while I’ve been wondering about the lifetime behavior of custom ServiceHostFactory classes hosted in IIS. Does IIS create an instance per request? Or a single instance to handle all requests?

I decided to find out, so I wrote a little test service. The conclusion seems to be that there is only a single instance that servers as a factory for all requests. This is very fortunate, since it gives us an excellent place to host a DI Container. The container can then manage the lifetime of all components, including Singletons that will live for the duration of the process.

If you are curious how I arrived at this conclusion, here’s the code I wrote. I started out with this custom ServiceHostFactory:

public class PocServiceHostFactory : ServiceHostFactory

    private static int number
= 1;

    public PocServiceHostFactory()

        Interlocked.Increment(

            ref PocServiceHostFactory.number);

    protected override ServiceHost CreateServiceHost(

        Type serviceType, Uri[]
baseAddresses)

        return new PocServiceHost(

            PocServiceHostFactory.number,
serviceType,

            baseAddresses);

The idea is that every time a new instance of ServiceHostFactory is created, the static number is incremented.

The PocServiceHostFactory just forwards the number to the PocServiceHost:

public class PocServiceHost : ServiceHost

    public PocServiceHost(int number, Type serviceType,

        Uri[]
baseAddresses)

        : base(serviceType,
baseAddresses)

        foreach (var cd in

            this.ImplementedContracts.Values)

            cd.Behaviors.Add(

                new NumberServiceInstanceProvider(

                    number));

The PocServiceHost just forwards the number to the NumberServiceInstanceProvider:

public class NumberServiceInstanceProvider :

    IInstanceProvider, IContractBehavior

    private readonly int number;

    public NumberServiceInstanceProvider(int number)

        this.number
= number;

   
#region IInstanceProvider Members

    public object GetInstance(

        InstanceContext instanceContext,

        Message message)

        return this.GetInstance(instanceContext);

    public object GetInstance(

        InstanceContext instanceContext)

        return new NumberService(this.number);

    public void ReleaseInstance(

        InstanceContext instanceContext,

        object instance)

   
#endregion

   
#region IContractBehavior Members

    public void AddBindingParameters(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint,

        BindingParameterCollection bindingParameters)

    public void ApplyClientBehavior(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint,

        ClientRuntime clientRuntime)

    public void ApplyDispatchBehavior(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint,

        DispatchRuntime dispatchRuntime)

        dispatchRuntime.InstanceProvider = this;

    public void Validate(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint)

   
#endregion

The relevant part of NumberServiceInstanceProvider is the GetInstanceMethod that simply forwards the number to the NumberService:

public class NumberService : INumberService

    private readonly int number;

    public NumberService(int number)

        this.number
= number;

   
#region INumberService Members

    public int GetNumber()

        return this.number;

   
#endregion

As you can see, NumberService simply returns the injected number.

The experiment is now to host NumberService in IIS using PocServiceHostFactory. If there is only one ServiceHostFactory per application process, we would expect that the same number (2) is returned every time we invoke the GetNumber operation. If, on the other hand, a new instance of ServiceHostFactory is created per request, we would expect the number to increase for every request.

To test this I spun up a few instances of WcfTestClient.exe and invoked the operation. It consistently returns 2 across multiple clients and multiple requests. This supports the hypothesis that there is only one ServiceHostFactory per service process.

Fun with literal extensions and Ambient Context

Mark Seemann — Tue, 27 Apr 2010 04:24:25 GMT

My book contains a section on the Ambient Context pattern that uses a TimeProvider as an example. It’s used like this:

this.closedAt
= TimeProvider.Current.UtcNow;

Yesterday I was TDDing a state machine that consumes TimeProvider and needed to freeze and advance time at different places in the test. Always on the lookout for making unit tests more readable, I decided to have a little fun with literal extensions and TimeProvider. I ended up with this test:

//
Fixture setup

var fixture
= new WcfFixture();

DateTime.Now.Freeze();

fixture.Register(1.Minutes());

var sut
= fixture.CreateAnonymous<CircuitBreaker>();

sut.PutInOpenState();

2.Minutes().Pass();

//
Exercise system

sut.Guard();

//
Verify outcome

Assert.IsInstanceOfType(sut.State,

    typeof(HalfOpenCircuitState));

//
Teardown

There are several items of note. Imagine that we can freeze time!

DateTime.Now.Freeze();

With the TimeProvider and an extension method, we can:

internal static void Freeze(this DateTime dt)

    var timeProviderStub
= new Mock<TimeProvider>();

    timeProviderStub.SetupGet(tp => tp.UtcNow).Returns(dt);

    TimeProvider.Current
= timeProviderStub.Object;

This effectively sets up the TimeProvider to always return the same time.

Later in the test I state that 2 minutes pass:

2.Minutes().Pass();

I particularly like the grammatically correct English. This is accomplished with a combination of a literal extension and changing the state of TimeProvider.

First, the literal extension:

internal static TimeSpan Minutes(this int m)

    return TimeSpan.FromMinutes(m);

Given the TimeSpan returned from the Minutes method, I can now invoke the Pass extension method:

internal static void Pass(this TimeSpan ts)

    var previousTime
= TimeProvider.Current.UtcNow;

    (previousTime + ts).Freeze();

Note that I just add the TimeSpan to the current time and invoke the Freeze extension method with the new value.

Last, but not least, I should point out that the PutInOpenState method isn’t some smelly test-specific method on the SUT, but rather yet another extension method.

Changing Windsor lifestyles after the fact

Mark Seemann — Mon, 26 Apr 2010 05:09:42 GMT

I recently had the need to change the lifestyles of all components in a WindsorContainer (read on to the end if you want to know why). This turned out to be amazingly simple to do.

The problem was this: I had numerous components registered in a WindsorContainer, some of them as Singletons, some as Transients and yet again some as PerWebRequest. Configuration was even defined in numerous IWindsorInstallers, including some distributed XML files. I now needed to spin up a second container with the same configuration as the first one, except that the lifestyles should be all Singletons across the board.

This can be easily accomplished by implementing a custom IContributeComponentModelConstruction type. Here’s a simple example:

Consider this IWindsorInstaller:

public class FooInstaller : IWindsorInstaller

   
#region IWindsorInstaller Members

    public void Install(IWindsorContainer container,

        IConfigurationStore store)

        container.Register(Component

            .For<IFoo>()

            .ImplementedBy<Foo>()

            .LifeStyle.Transient);

   
#endregion

The important point to notice is that it registers the lifestyle as Transient. In other words, this container will always return new Foo instances:

var container
= new WindsorContainer();

container.Install(new FooInstaller());

We can override this behavior by adding this custom IContributeComponentModelConstruction:

public class SingletonEqualizer :

    IContributeComponentModelConstruction

    public void ProcessModel(IKernel kernel,

        ComponentModel model)

        model.LifestyleType = LifestyleType.Singleton;

In this very simple example, I always set the lifestyle type to the same value, but obviously we can write as complex code in the ProcessModel method as we would like. We can now configure the container like this:

var container
= new WindsorContainer();

container.Kernel.ComponentModelBuilder

    .AddContributor(new SingletonEqualizer());

container.Install(new FooInstaller());

With this configuration we will now get the same instance of Foo every time we Resolve IFoo.

We did I need this? Because my application is a web application and I’m using the PerWebRequest lifestyle in a number of places. However, I needed to spin up a second container that would compose object hierarchies for a background process. This background process needs the same component configuration as the rest of the application, but can’t use the PerWebRequest lifestyle as there will be no web request available to the background process. Hence the need to change lifestyles across the board.

Dependency Injection is Loose Coupling

Mark Seemann — Wed, 07 Apr 2010 19:49:11 GMT

It seems to me that I’ve lately encountered a particular mindset towards Dependency Injection (DI). People seem to think that it’s only really good for replacing one data access implementation with another. Once you get to that point, you know that the following argument isn’t far behind:

“That’s all well and good, but we know for certain that we will never exchange [insert name of RDBMS here] with anything else in this application.”

Apart from the hubris of making such a bold statement about the future of any software endeavor, such a statement reveals the narrow view on DI that its only purpose is for replacing data access components – and perhaps for unit testing.

Those are relevant reasons for using DI, but they are only some of the reasons. Let’s briefly revisit why we employ DI.

We use DI to enable loose coupling.

DI is only a means to an end. Even if you never intend to replace your database and even if you never want to write a single unit test, DI still offers benefits in form of a more maintainable code base. The loose coupling gives you better separation of concerns because it allows you to apply the Open/Closed Principle.

Example coming right up:

Imagine that we need to implement a PrécisViewModel class with a TopSellers property that returns an IEnumerable<string>. To implement this class, we have a data access component. Let’s use the ubiquitous Repository pattern and define IProductRepository to see where that leads us:

public interface IProductRepository

    IEnumerable<Product>
SelectTopSellers();

We can now implement PrécisViewModel like this:

public class PrécisViewModel

    private readonly IProductRepository repository;

    public PrécisViewModel(IProductRepository repository)

        if (repository
== null)

            throw new ArgumentNullException("repository");

        this.repository
= repository;

    public IEnumerable<string>
TopSellers

get

            var topSellers
=

                this.repository.SelectTopSellers();

            return from p in topSellers

                   select p.Name;

Nothing fancy is going on here. It’s just straight Constructor Injection at work.

Obviously, we can now implement and use a SQL Server-based repository:

var repository
= new SqlProductRepository();

var vm
= new PrécisViewModel(repository);

So what does all this loose coupling buy us? It doesn’t seem to help us a lot.

The real benefit is not yet apparent, but it should become more obvious when we start adding requirements. Let’s start with some caching. It turns out that the SelectTopSellers implementation is slow, so we would like to add some caching somewhere.

Where should we add this caching functionality? Without loose coupling, we would more or less be constrained to adding it to either PrécisViewModel or SqlProductRepository, but both have issues:

First of all we would be violating the Single Responsibility Principle (SRP) in both cases.
If we implement caching in PrécisViewModel, other consumers of the SelectTopSellers would not benefit from it.
If we implement caching in SqlProductRepository, it wouldn’t be available for any other IProductRepository implementations.

Since the premise for this post is that we will never use any other database than SQL Server, implementing caching directly in SqlProductRepository sounds like the correct choice, but we would still be violating the SRP, and thus making our code more difficult to maintain.

A better solution is to introduce a caching Decorator like this one:

public class CachingProductRepository : IProductRepository

    private readonly ICache cache;

    private readonly IProductRepository repository;

    public CachingProductRepository(

        IProductRepository repository, ICache cache)

        if (repository
== null)

            throw new ArgumentNullException("repository");

        if (cache
== null)

            throw new ArgumentNullException("cache");

        this.cache
= cache;

        this.repository
= repository;

   
#region IProductRepository Members

    public IEnumerable<Product>
SelectTopSellers()

        return this.cache

            .Retrieve<IEnumerable<Product>>("topSellers",

                this.repository.SelectTopSellers);

   
#endregion

For completeness sake is here the definition of ICache:

public interface ICache

    T Retrieve<T>(string key, Func<T>
readThrough);

The point is that CachingProductRepository extends any IProductRepository we provide to it (including SqlProductRepository) without modifying it. Thus, we have satisfied both the OCP and the SRP.

Just to drive home the point, let us assume that we also wish to record execution times for various methods for purposes of SLA compliance. We can do this by introducing yet another Decorator:

public class PerformanceMeasuringProductRepository :

    IProductRepository

    private readonly IProductRepository repository;

    private readonly IStopwatch stopwatch;

    public PerformanceMeasuringProductRepository(

        IProductRepository repository,

        IStopwatch stopwatch)

        if (repository
== null)

            throw new ArgumentNullException("repository");

        if (stopwatch
== null)

            throw new ArgumentNullException("stopwatch");

        this.repository
= repository;

        this.stopwatch
= stopwatch;

   
#region IProductRepository Members

    public IEnumerable<Product>
SelectTopSellers()

        var timer
= this.stopwatch

            .StartMeasuring("SelectTopSellers");

        var topSellers
=

            this.repository.SelectTopSellers();

        timer.StopMeasuring();

        return topSellers;

   
#endregion

Once again, we modified neither SqlProductRepository nor CachingProductRepository to introduce this new feature. We can implement security and auditing features by following the same principle.

To me, this is what loose coupling (and DI) is all about. That we can also replace data access components and unit test using dynamic mocks are very fortunate side effects, but the loose coupling is valuable in itself because it enables us to write more maintainable code.

We don’t even need a DI Container to wire up all these repositories (although it sure would be helpful). Here’s how we can do it with Poor Man’s DI:

IProductRepository repository
=

    new PerformanceMeasuringProductRepository(

        new CachingProductRepository(

            new SqlProductRepository(), new Cache()

),

        new RealStopwatch()

);

var vm
= new PrécisViewModel(repository);

The next time someone on your team claims that you don’t need DI because the choice of RDBMS is fixed, you can tell them that it’s irrelevant. The choice is between DI and Spaghetti Code.

Service Locator is an Anti-Pattern

Mark Seemann — Wed, 03 Feb 2010 21:49:39 GMT

Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right?

No, it’s actually an anti-pattern and should be avoided.

Let’s examine why this is so. In short, the problem with Service Locator is that it hides a class’ dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.

OrderProcessor example

As an example, let’s pick a hot topic in DI these days: an OrderProcessor. To process an order, the OrderProcessor must validate the order and ship it if valid. Here’s an example using a static Service Locator:

public class OrderProcessor : IOrderProcessor

    public void Process(Order order)

        var validator
= Locator.Resolve<IOrderValidator>();

        if (validator.Validate(order))

            var shipper
= Locator.Resolve<IOrderShipper>();

            shipper.Ship(order);

The Service Locator is used as a replacement for the new operator. It looks like this:

public static class Locator

    private readonly static Dictionary<Type, Func<object>>

        services = new Dictionary<Type, Func<object>>();

    public static void Register<T>(Func<T>
resolver)

        Locator.services[typeof(T)]
= () => resolver();

    public static T
Resolve<T>()

        return (T)Locator.services[typeof(T)]();

    public static void Reset()

        Locator.services.Clear();

We can configure the Locator using the Register method. A ‘real’ Service Locator implementation would be much more advanced than this, but this example captures the gist of it.

This is flexible and extensible, and it even supports replacing services with Test Doubles, as we will see shortly.

Given that, then what could be the problem?

API usage issues

Let’s assume for a moment that we are simply consumers of the OrderProcessor class. We didn’t write it ourselves, it was given to us in an assembly by a third party, and we have yet to look at it in Reflector.

This is what we get from IntelliSense in Visual Studio:

Okay, so the class has a default constructor. That means I can simply create a new instance of it and invoke the Process method right away:

var order
= new Order();

var sut
= new OrderProcessor();

sut.Process(order);

Alas, running this code surprisingly throws a KeyNotFoundException because the IOrderValidator was never registered with Locator. This is not only surprising, it may be quite baffling if we don’t have access to the source code.

By perusing the source code (or using Reflector) or consulting the documentation (ick!) we may finally discover that we need to register an IOrderValidator instance with Locator (a completely unrelated static class) before this will work.

In a unit test test, this can be done like this:

var validatorStub
= new Mock<IOrderValidator>();

validatorStub.Setup(v => v.Validate(order)).Returns(false);

Locator.Register(()
=> validatorStub.Object);

What is even more annoying is that because the Locator’s internal store is static, we need to invoke the Reset method after each unit test, but granted: that is mainly a unit testing issue.

All in all, however, we can’t reasonably claim that this sort of API provides a positive developer experience.

Maintenance issues

While this use of Service Locator is problematic from the consumer’s point of view, what seems easy soon becomes an issue for the maintenance developer as well.

Let’s say that we need to expand the behavior of OrderProcessor to also invoke the IOrderCollector.Collect method. This is easily done, or is it?

public void Process(Order order)

    var validator
= Locator.Resolve<IOrderValidator>();

    if (validator.Validate(order))

        var collector
= Locator.Resolve<IOrderCollector>();

        collector.Collect(order);

        var shipper
= Locator.Resolve<IOrderShipper>();

        shipper.Ship(order);

From a pure mechanistic point of view, that was easy – we simply added a new call to Locator.Resolve and invoke IOrderCollector.Collect.

Was this a breaking change?

This can be surprisingly hard to answer. It certainly compiled fine, but broke one of my unit tests. What happens in a production application? The IOrderCollector interface may already be registered with the Service Locator because it is already in use by other components, in which case it will work without a hitch. On the other hand, this may not be the case.

The bottom line is that it becomes a lot harder to tell whether you are introducing a breaking change or not. You need to understand the entire application in which the Service Locator is being used, and the compiler is not going to help you.

Variation: Concrete Service Locator

Can we fix these issues in some way?

One variation commonly encountered is to make the Service Locator a concrete class, used like this:

public void Process(Order order)

    var locator
= new Locator();

    var validator
= locator.Resolve<IOrderValidator>();

    if (validator.Validate(order))

        var shipper
= locator.Resolve<IOrderShipper>();

        shipper.Ship(order);

However, to be configured, it still needs a static in-memory store:

public class Locator

    private readonly static Dictionary<Type, Func<object>>

        services = new Dictionary<Type, Func<object>>();

    public static void Register<T>(Func<T>
resolver)

        Locator.services[typeof(T)]
= () => resolver();

    public T
Resolve<T>()

        return (T)Locator.services[typeof(T)]();

    public static void Reset()

        Locator.services.Clear();

In other words: there’s no structural difference between the concrete Service Locator and the static Service Locator we already reviewed. It has the same issues and solves nothing.

Variation: Abstract Service Locator

A different variation seems more in line with true DI: the Service Locator is a concrete class implementing an interface.

public interface IServiceLocator

    T Resolve<T>();

public class Locator : IServiceLocator

    private readonly Dictionary<Type, Func<object>>
services;

    public Locator()

        this.services
= new Dictionary<Type, Func<object>>();

    public void Register<T>(Func<T>
resolver)

        this.services[typeof(T)]
= () => resolver();

    public T
Resolve<T>()

        return (T)this.services[typeof(T)]();

With this variation it becomes necessary to inject the Service Locator into the consumer. Constructor Injection is always a good choice for injecting dependencies, so OrderProcessor morphs into this implementation:

public class OrderProcessor : IOrderProcessor

    private readonly IServiceLocator locator;

    public OrderProcessor(IServiceLocator locator)

        if (locator
== null)

            throw new ArgumentNullException("locator");

        this.locator
= locator;

    public void Process(Order order)

        var validator
=

            this.locator.Resolve<IOrderValidator>();

        if (validator.Validate(order))

            var shipper
=

                this.locator.Resolve<IOrderShipper>();

            shipper.Ship(order);

Is this good, then?

From a developer perspective, we now get a bit of help from IntelliSense:

What does this tell us? Nothing much, really. Okay, so OrderProcessor needs a ServiceLocator – that’s a bit more information than before, but it still doesn’t tell us which services are needed. The following code compiles, but crashes with the same KeyNotFoundException as before:

var order
= new Order();

var locator
= new Locator();

var sut
= new OrderProcessor(locator);

sut.Process(order);

From the maintenance developer’s point of view, things don’t improve much either. We still get no help if we need to add a new dependency: is it a breaking change or not? Just as hard to tell as before.

Summary

The problem with using a Service Locator isn’t that you take a dependency on a particular Service Locator implementation (although that may be a problem as well), but that it’s a bona-fide anti-pattern. It will give consumers of your API a horrible developer experience, and it will make your life as a maintenance developer worse because you will need to use considerable amounts of brain power to grasp the implications of every change you make.

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.

You can read more about DI patterns and anti-patterns in my upcoming book.

Refactoring to Aggregate Services

Mark Seemann — Tue, 02 Feb 2010 20:56:44 GMT

In a follow-up to his earlier post on Constructor Over-Injection, Jeffrey Palermo changes his stance on Constructor Over-Injection from anti-pattern to the more palatable code smell. In this post I introduce the concept of an Aggregate Service and outline a refactoring that addresses this code smell.

If I should extract a core message from Jeffrey Palermo’s blog post it would be that it’s a code smell if you have a class that takes too many dependencies in its constructor.

I can only agree, but only so far as it’s a code smell. However, it has nothing to do with DI in general or Constructor Injection specifically. Rather, it’s a smell that indicates a violation of the Single Responsibility Principle (SRP). Let’s review the example constructor:

public OrderProcessor(IOrderValidator validator,

                      IOrderShipper shipper,

                      IAccountsReceivable receivable,

                      IRateExchange exchange,

                      IUserContext userContext)

In this version, I even added IOrderShipper back in as I described in my earlier post. Surely, five constructor parameters are too many.

Constructor Injection makes SRP violations glaringly obvious.

What’s not to like? My personal threshold lies somewhere around 3-4 constructor parameters, so whenever I hit three, I start to consider if I could perhaps aggregate some of the dependencies into a new type.

I call such a type an Aggregate Service. It’s closely related to Parameter Objects, but the main difference is that a Parameter Object only moves the parameters to a common root, while an Aggregate Service hides the aggregate behavior behind a new abstraction. While the Aggregate Service may start its life as a result of a pure mechanistic refactoring, it often turns out that the extracted behavior represents a Domain Concept in its own right. Congratulations: you’ve just move a little closer to adhering to the SRP!

Let’s look at Jeffrey Palermo’s OrderProcessor example. The core implementation of the class is reproduced here (recall that in my version, IOrderShipper is also an injected dependency):

public SuccessResult Process(Order order)

    bool isValid
= _validator.Validate(order);

    if (isValid)

        Collect(order);

        _shipper.Ship(order);

    return CreateStatus(isValid);

private void Collect(Order order)

    User user
= _userContext.GetCurrentUser();

    Price price
= order.GetPrice(_exchange, _userContext);

    _receivable.Collect(user, price);

If you examine the code it should quickly become apparent that the Collect method encapsulates a cluster of dependencies: IAccountsReceivable, IRateExchange and IUserContext. In this case it’s pretty obvious because they are already encapsulated in a single private method. In real production code, you may need to perform a series of internal refactorings before a pattern starts to emerge and you can extract an interface that aggregates several dependencies.

Now that we have identified the cluster of dependencies, we can extract an interface that closely resembles the Collect method:

public interface IOrderCollector

    void Collect(Order order);

In lieu of a better name, I simply chose to call it IOrderCollector, but what’s interesting about extracting Aggregate Services is that over time, they often turn out to be previously implicit Domain Concepts that we have now dragged out in the open and made explicit.

We can now inject IOrderCollector into OrderProcessor and change the implementation of the private Collect method:

private void Collect(Order order)

    _collector.Collect(order);

Next, we can remove the redundant dependencies, leaving us with this constructor:

public OrderProcessor(IOrderValidator validator,

                      IOrderShipper shipper,

                      IOrderCollector collector)

With three constructor parameters it’s much more acceptable, but we can always consider repeating the procedure and extract a new Aggregate Service that aggregates IOrderShipper and IOrderCollector.

The original behavior from the Collect method is still required, but is now implemented in the OrderCollector class:

public class OrderCollector : IOrderCollector

    private readonly IUserContext _userContext;

    private readonly IRateExchange _exchange;

    private readonly IAccountsReceivable _receivable;

    public OrderCollector(IAccountsReceivable receivable,

                          IRateExchange exchange,

                          IUserContext userContext)

        _receivable = receivable;

        _exchange = exchange;

        _userContext = userContext;

   
#region IOrderCollector Members

    public void Collect(Order order)

        User user
= _userContext.GetCurrentUser();

        Price price
=

            order.GetPrice(_exchange, _userContext);

        _receivable.Collect(user, price);

   
#endregion

Here’s another class with three constructor parameters, which falls within the reasonable range. However, once again, we can begin to consider whether the interaction between IUserContext and the Order could be better modeled.

In outline form, the Introduce Aggregate Service refactoring follows these steps:

Analyze how dependencies interact to identify clusters of behavior.
Extract an interface from these clusters.
Copy the original implementation to a class that implements the new interface.
Inject the new interface into the consumer.
Replace the original implementation with a call the new dependency.
Remove the redundant dependencies.
Rinse and repeat :)

The beauty of Aggregate Services is that we can keep wrapping one Aggregate Service in new Aggregate Services to define more and more coarse-grained building blocks as we get closer and closer to the application boundary.

Keeping each class and its dependencies to simple interactions also makes it much easier to unit test all of them because none of them do anything particularly complex.

Adhering strictly to Constructor Injection makes it easy to see when one violates the SRP and should refactor to an Aggregate Service.

What's so dangerous about a DI attribute?

Mark Seemann — Wed, 27 Jan 2010 19:36:34 GMT

In a reaction to Uncle Bob's recent post on Dependency Injection Inversion, Colin Decker writes that he doesn't consider the use of the single Guice @Inject annotation particularly problematic. As I read it, the central argument is that

annotations are not code. By themselves, they do nothing.

I'll have to take that at face value, but if we translate this reasoning to .NET it certainly holds true. Attributes don't do anything by themselves.

I'm not aware of any DI Container for .NET that requires us to sprinkle attributes all over our code to work (I don't consider MEF a DI Container), but for the sake of argument, let's assume that such a container exists (let's call it Needle). Would it be so bad if we had to liberally apply the Needle [Inject] attribute in large parts of our code bases?

Colin suggests no. As usual, my position is that it depends, but in most cases I would consider it bad.

If Needle is implemented like most libraries, InjectAttribute is just one of many types that make up the entire API. Other types would include NeedleContainer and its associated classes.

Java annotations may work differently, but in .NET we need to reference a library to apply one of its attributes. To apply the [Inject] attribute, we would have to reference Needle, and herein lies the problem.

Once Needle is referenced, it becomes much easier for a junior developer to accidentally start directly using other parts of the Needle API. Particularly he or she may start using Needle as a Service Locator. When that happens, Needle is no longer a passive participant of the code, but a very active one, and it becomes much harder to separate the code from the Container.

To paraphrase Uncle Bob: I don't want to write a Needle application.

We can't even protect ourselves from accidental usage by writing a convention-based unit test that fails if Needle is referenced by our code, because it must be referenced for the [Inject] attribute to be applied.

The point is that the attribute drags in a reference to the entire container, which in my opinion is a bad thing.

So when would it be less problematic?

If Needle was implemented in such a way that InjectAttribute was defined in an assembly that only contains that one type, and the rest of Needle was implemented in a different assembly, the attribute wouldn't drag the rest of the container along.

Whether this whole analysis makes sense at all in Java, and whether Guice is implemented like that, I can't say, but in most cases I would consider even a single attribute to be unacceptable pollution of my code base.

IWindsorInstaller

Mark Seemann — Tue, 26 Jan 2010 19:24:51 GMT

Reacting to my previous post, Krzysztof Koźmic was so kind to point out to me that I really should be using an IWindsorInstaller instead of writing the registration code in a static helper method (it did make me cringe a bit).

As it turns out, IWindsorInstaller is not a particularly well-described feature of Castle Windsor, so here's a quick introduction. Fortunately, it is very easy to understand.

The idea is simply to package configuration code in reusable modules (just like the Guice modules from Uncle Bob's post).

Refactoring the bootstrap code from my previous post, I can now move all the container configuration code into a reusable module:

public class BillingContainerInstaller : IWindsorInstaller

{

    #region IWindsorInstaller Members

    public void Install(IWindsorContainer container,

        IConfigurationStore store)

    {

        container.AddComponent<TransactionLog, 

            DatabaseTransactionLog>();

        container.AddComponent<CreditCardProcessor,

            MyCreditCardProcessor>();

        container.AddComponent<BillingService>();

    }

    #endregion

}

While I was at it, I also changed from the fluent registration API to the generic registration methods as I didn't really need the full API, but I could have left it as it was.

BillingContainerInstaller implements IWindsorInstaller, and I can now configure my container instance like this:

var container = new WindsorContainer();

container.Install(new BillingContainerInstaller());

The Install method takes a parameter array of IWindsorInstaller instances, so you can pass as many as you'd like.

Dependency Injection Inversion in .NET

Mark Seemann — Mon, 25 Jan 2010 20:48:27 GMT

About a week ago Uncle Bob published a post on Dependency Injection Inversion that caused quite a stir in the tiny part of the .NET community I usually pretend to hang out with. Twitter was alive with much debate, but Ayende seems to sum up the .NET DI community's sentiment pretty well:

if this is a typical example of IoC usage in the Java world, then [Uncle Bob] should peek over the fence to see how IoC is commonly implemented in the .Net space

Despite having initially left a more or less positive note to Uncle Bob's post, after having re-read it carefully, I am beginning to think the same, but instead of just telling everyone how much greener the grass is on the .NET side, let me show you.

First of all, let's translate Uncle Bob's BillingService to C#:

public class BillingService

{

    private readonly CreditCardProcessor processor;

    private readonly TransactionLog transactionLog;

    public BillingService(CreditCardProcessor processor,

        TransactionLog transactionLog)

    {

        if (processor
== null)

        {

            throw new ArgumentNullException("processor");

        }

        if (transactionLog
== null)

        {

            throw new ArgumentNullException("transactionLog");

        }

        this.processor
= processor;

        this.transactionLog
= transactionLog;

    }

    public void ProcessCharge(int amount, string id)

    {

        var approval
= this.processor.Approve(amount, id);

        this.transactionLog.Log(string.Format(

            "Transaction
by {0} for {1} {2}", id, amount, 

            this.GetApprovalCode(approval)));

    }

    private string GetApprovalCode(bool approval)

    {

        return approval
? "approved" : "denied";

    }

}

It's nice how easy it is to translate Java code to C#, but apart from casing and other minor deviations, let's focus on the main difference. I've added Guard Clauses to protect the injected dependencies against null values as I consider this an essential and required part of Constructor Injection – I think Uncle Bob should have added those as well, but he might have omitted them for brevity.

If you disregard the Guard Clauses, the C# version is a logical line of code shorter than the Java version because it has no DI attribute like Guice's @Inject.

Does this mean that we can't do DI with the C# version of BillingService? Uncle Bob seems to imply that we can do Dependency Inversion, but not Dependency Injection - or is it the other way around? I can't really make head or tails of that part of the post…

The interesting part is that in .NET, there's no difference! We can use DI Containers with the BillingService without sprinkling DI attributes all over our code base. The BillingService class has no reference to any DI Container.

It does, however, use the central DI pattern Constructor Injection. .NET DI Containers know all about this pattern, and with .NET's static type system they know all they need to know to wire dependencies up correctly. (I thought that Java had a static type system as well, but perhaps I am mistaken.) The .NET DI Containers will figure it out for you – you don't have to explicitly tell them how to invoke a constructor with two parameters.

We can write an entire application by using Constructor Injection and stacking dependencies without ever referencing a container!

Like the Lean concept of the Last Responsible Moment, we can wait until the application's entry point to decide how we will wire up the dependencies.

As Uncle Bob suggests, we can use Poor Man's DI and manually create the dependencies directly in Main, but as Ayende correctly observes, that only looks like an attractive alternative because the example is so simple. For complex dependency graphs, a DI Container is a much better choice.

With the C# version of BillingService, which DI Container must we select?

It doesn't matter: we can choose whichever one we would like because we have been following patterns instead of using a framework.

Here's an example of an implementation of Main using Castle Windsor:

public static void Main(string[]
args)

{

    var container = new WindsorContainer();

    Program.Configure(container);

    var billingService =

        container.Resolve<BillingService>();

    billingService.ProcessCharge(2034, "Bob");

}

This looks a lot like Uncle Bob's first Guice example, but instead of injecting a BillingModule into the container, we can configure it inline or in a helper method:

private static void Configure(WindsorContainer container)

{

    container.Register(Component

        .For<TransactionLog>()

        .ImplementedBy<DatabaseTransactionLog>());

    container.Register(Component

        .For<CreditCardProcessor>()

        .ImplementedBy<MyCreditCardProcessor>());

    container.Register(Component.For<BillingService>());

}

This corresponds more or less to the Guice-specific BillingModule, although Windsor also requires us to register the concrete BillingService as a component (this last step varies a bit from DI Container to DI Container – it is, for example, redundant in Unity).

Imagine that in the future we want to rewire this program to use a different DI Container. The only piece of code we need to change is this Composition Root. We need to change the container declaration and configuration and then we are ready to use a different DI Container.

The bottom line is that Uncle Bob's Dependency Injection Inversion is redundant in .NET. Just use a few well-known design patterns and principles and you can write entire applications with DI-friendly, DI-agnostic code bases.

I recently posted a first take on guidelines for writing DI-agnostic code. I plan to evolve these guiding principles and make them a part of my upcoming book.

Enabling DI for Lazy Components

Mark Seemann — Wed, 20 Jan 2010 18:08:36 GMT

My previous post led to this comment by Phil Haack:

Your LazyOrderShipper directly instantiates an OrderShipper. What about the dependencies that OrderShipper might require? What if those dependencies are costly?

I didn't want to make my original example more complex than necessary to get the point across, so I admit that I made it a bit simpler than I might have liked. However, the issue is easily solved by enabling DI for the LazyOrderShipper itself.

As always, when the dependency's lifetime may be shorter than the consumer, the solution is to inject (via the constructor!) an Abstract Factory, as this modification of LazyOrderShipper shows:

public class LazyOrderShipper2 : IOrderShipper

    private readonly IOrderShipperFactory factory;

    private IOrderShipper shipper;

    public LazyOrderShipper2(IOrderShipperFactory factory)

        if (factory
== null)

            throw new ArgumentNullException("factory");

        this.factory
= factory;

   
#region IOrderShipper Members

    public void Ship(Order order)

        if (this.shipper
== null)

            this.shipper
= this.factory.Create();

        this.shipper.Ship(order);

   
#endregion

But, doesn't that reintroduce the OrderShipperFactory that I earlier claimed was a bad design?

No, it doesn't, because this IOrderShipperFactory doesn't rely on static configuration. The other point is that while we do have an IOrderShipperFactory, the original design of OrderProcessor is unchanged (and thus blissfully unaware of the existence of this Abstract Factory).

The lifetime of the various dependencies is completely decoupled from the components themselves, and this is as it should be with DI.

This version of LazyOrderShipper is more reusable because it doesn't rely on any particular implementation of OrderShipper – it can Lazily create any IOrderShipper.

Rebuttal: Constructor over-injection anti-pattern

Mark Seemann — Wed, 20 Jan 2010 16:28:03 GMT

Jeffrey Palermo recently posted a blog post titled Constructor over-injection anti-pattern – go read his post first if you want to be able to follow my arguments.

His point seems to be that Constructor Injection can be an anti-pattern if applied too much, particularly if a consumer doesn't need a particular dependency in the majority of cases.

The problem is illustrated in this little code snippet:

bool isValid
= _validator.Validate(order);

if (isValid)

    _shipper.Ship(order);

If the Validate method returns false often, the shipper dependency is never needed.

This, he argues, can lead to inefficiencies if the dependency is costly to create. It's not a good thing to require a costly dependency if you are not going to use it in a lot of cases.

That sounds like a reasonable statement, but is it really? And is the proposed solution a good solution?

No, this isn't a reasonable statement, and the proposed solution isn't a good solution.

It would seem like there's a problem with Constructor Injection, but in reality the problem is that it is being used incorrectly and in too constrained a way.

The proposed solution is problematic because it involves tightly coupling the code to OrderShipperFactory. This is more or less a specialized application of the Service Locator anti-pattern.

Consumers of OrderProcessor have no static type information to warn them that they need to configure the OrderShipperFactory.CreationClosure static member - a completely unrelated type. This may technically work, but creates a very developer-unfriendly API. IntelliSense isn't going to be of much help here, because when you want to create an instance of OrderProcessor, it's not going to remind you that you need to statically configure OrderShipperFactory first. Enter lots of run-time exceptions.

Another issue is that he allows a concrete implementation of an interface to change the design of the OrderProcessor class - that's hardly in the spirit of the Liskov Substitution Principle. I consider this a strong design smell.

One of the commenters (Alwin) suggests instead injecting an IOrderShipperFactory. While this is a better option, it still suffers from letting a concrete implementation influence the design, but there's a better solution.

First of all we should realize that the whole case is a bit construed because although the IOrderShipper implementation may be expensive to create, there's no need to create a new instance for every OrderProcessor. Instead, we can use the so-called Singleton lifetime style where we share or reuse a single IOrderShipper instance between multiple OrderProcessor instances.

The beauty of this is that we can wait making that decision until we wire up the actual dependencies. If we have implementations of IOrderShipper that are inexpensive to create, we may still decide to create a new instance every time.

There may still be a corner case where a shared instance doesn't work for a particular implementation (perhaps because it's not thread-safe). In such cases, we can use Lazy loading to create a LazyOrderShipper like this (for clarity I've omitted making this implementation thread-safe, but that would be trivial to do):

public class LazyOrderShipper : IOrderShipper

    private OrderShipper shipper;

   
#region IOrderShipper Members

    public void Ship(Order order)

        if (this.shipper
== null)

            this.shipper
= new OrderShipper();

        this.shipper.Ship(order);

   
#endregion

Notice that this implementation of IOrderShipper only creates the expensive OrderShipper instance when it needs it.

Instead of directly injecting the expensive OrderShipper instance directly into OrderProcessor, we wrap it in the LazyOrderShipper class and inject that instead. The following test proves the point:

[TestMethod]

public void OrderProcessorIsFast()

    //
Fixture setup

    var stopwatch
= new Stopwatch();

    stopwatch.Start();

    var order
= new Order();

    var validator
= new Mock<IOrderValidator>();

    validator.Setup(v =>

        v.Validate(order)).Returns(false);

    var shipper
= new LazyOrderShipper();

    var sut
= new OrderProcessor(validator.Object,

        shipper);

    //
Exercise system

    sut.Process(order);

    //
Verify outcome

    stopwatch.Stop();

    Assert.IsTrue(stopwatch.Elapsed
<

        TimeSpan.FromMilliseconds(777));

    Console.WriteLine(stopwatch.Elapsed);

    //
Teardown

This test is significantly faster than 777 milliseconds because the OrderShipper never comes into play. In fact, the stopwatch instance reports that the elapsed time was around 3 ms!

The bottom line is that Constructor Injection is not an anti-pattern. On the contrary, it is the most powerful DI pattern available, and you should think twice before deviating from it.

MEF TechTalk with me

Mark Seemann — Sun, 20 Dec 2009 19:56:33 GMT

I'll be doing a TechTalk on the Managed Extensibility Framework and Dependency Injection at Microsoft Denmark January 20th 2010.

The talk will be in Danish. Details and sign-up here.

Wiring ASP.NET MVC Error Handling with Castle Windsor

Mark Seemann — Mon, 14 Dec 2009 06:59:32 GMT

In my previous posts I discussed how to enable global error handling in ASP.NET MVC and how to inject a logging interface into the error handler. In these posts, I simplified things a bit to get my points across.

In production we don't use a custom ErrorHandlingControllerFactory to configure all Controllers with error handling, nor do we instantiate IExceptionFilters manually. What I described was the Poor Man's Dependency Injection (DI) approach, which I find most appropriate when describing DI concepts.

However, we really use Castle Windsor currently, so the wiring looks a bit different although it's still exactly the same thing that's going on. Neither ErrorHandlingActionInvoker nor LoggingExceptionFilter are any different than I have already described, but for completeness I wanted to share a bit of our Windsor code.

This is how we really wire our Controllers:

container.Register(AllTypes

    .FromAssemblyContaining(representativeControllerType)

    .BasedOn<Controller>()

    .ConfigureFor<Controller>(reg
=>

        reg.LifeStyle.PerWebRequest.ServiceOverrides(

            new {
ActionInvoker = typeof(

                ErrorHandlingControllerActionInvoker)

                .FullName })));

Most of this statement simply instructs Windsor to scan all types in the specified assembly for Controller implementations and register them. The interesting part is the ServiceOverrides method call that uses Windsor's rather excentric syntax for defining that the ActionInvoker property should be wired up with an instance of the component registered as ErrorHandlingControllerActionInvoker.

Since ErrorHandlingControllerActionInvoker itself expects an IExceptionFilter instance we need to configure at least one of these as well. Instead of one, however, we have two:

container.Register(Component.For<IExceptionFilter>()

    .ImplementedBy<LoggingExceptionFilter>());

container.Register(Component.For<IExceptionFilter>()

    .ImplementedBy<HandleErrorAttribute>());

This is Windsor's elegant way of registering Decorators: you simply register the Decorator before the decorated type, and it'll Auto-Wire everything for you.

Finally, we use a ControllerFactory very similar to the WindsorControllerFactory from the MVC Contrib project.

To reiterate: You don't have to use Castle Windsor to enable global error handling or logging in ASP.NET MVC. You can code it by hand as I've demonstrated in my previous posts, or you can use some other DI Container. The purpose of this post was simply to demonstrate one way to take it to the next level.

LoggingExceptionFilter

Mark Seemann — Mon, 07 Dec 2009 06:20:27 GMT

In a previous post I described how to enable global error handling in ASP.NET MVC applications. Although I spent some time talking about the importance of DRY, another major motivation for me was to enable Dependency Injection (DI) with exception handling so that I could log stack traces before letting ASP.NET MVC handle the exception.

With the ErrorHandlingControllerActionInvoker I described, we can inject any IExceptionFilter implementation. As an example I used HandleErrorAttribute, but obviously that doesn't log anything. Once again, it would be tempting to derive from HandleErrorAttribute and override its OnException method, but staying true to the Single Responsibility Principle as well as the Open/Closed Principle I rather prefer a Decorator:

public class LoggingExceptionFilter : IExceptionFilter

    private readonly IExceptionFilter filter;

    private readonly ILogWriter logWriter;

    public LoggingExceptionFilter(IExceptionFilter filter,

        ILogWriter logWriter)

        if (filter
== null)

            throw new ArgumentNullException("filter");

        if (logWriter
== null)

            throw new ArgumentNullException("logWriter");

        this.filter
= filter;

        this.logWriter
= logWriter;

   
#region IExceptionFilter Members

    public void OnException(ExceptionContext filterContext)

        this.logWriter.WriteError(filterContext.Exception);

        this.filter.OnException(filterContext);

   
#endregion

The LoggingExceptionFilter shown above is unabridged production code. This is all it takes to bridge the gap between IExceptionFilter and some ILogWriter interface (replace with the logging framework of your choice). Notice how it simply logs the error and then passes on exception handling to the decorated IExceptionFilter.

Currently we use HandleErrorAttribute as the decorated filter so that behavior stays as expected.

c.ActionInvoker =

    new ErrorHandlingControllerActionInvoker(

        new LoggingExceptionFilter(

            new HandleErrorAttribute(),
logWriter));

This is not too different from before, except that a LoggingExceptionFilter now decorates the HandleErrorAttribute instance.

Dependency Injection Podcast with me

Mark Seemann — Tue, 17 Nov 2009 18:58:47 GMT

Daniel Frost has published a podcast where he discusses Dependency Injection with me. It's about half an hour long and in Danish. Hear it here.

Using Castle Windsor's PerWebRequest lifestyle with ASP.NET MVC on IIS7

Mark Seemann — Tue, 17 Nov 2009 12:44:37 GMT

When using Castle Windsor in web applications you would want to register many of your components with a lifestyle that is associated with a single request. This is the purpose of the PerWebRequest lifestyle.

If you try that with ASP.NET MVC on IIS7, you are likely to receive the following error message:

Looks like you forgot to register the http module Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule
Add '<add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.MicroKernel" />' to the <httpModules> section on your web.config.

Unfortunately, following the instructions in the error message doesn't help. There's a discussion about this issue on the Castle Project Users forum, but the gist of it is that if you don't need to resolve components during application startup, this shouldn't be an issue, and indeed it isn't – it seems to be something else.

In my case I seem to have solved the problem by registering the HTTP module in configuration/system.webServer/modules instead of configuration/system.web/httpModules.

Although I haven't had the opportunity to dive into the technical details to understand why this works, this seems to solve the problem on both Windows Vista and Windows Server 2008.

Writing a book

Mark Seemann — Mon, 05 Oct 2009 18:13:50 GMT

For the last few months I've been writing a book for Manning tentatively titled Dependency Injection in .NET. The page about the book is now live at the Manning web site where you can read more about it and, if you would like, purchase an Early Access edition and read the chapters as they are being written.

If you have ever wanted to learn about Dependency Injection (DI) related to .NET, here's your chance!

At the moment I'm about a third of the way into the book, so there's still some way to go, but I hope to be done with it in 2010.

If you decide to purchase an Early Access edition, I'd love to receive your feedback in the online forum.