Strategy Pattern with Castle Windsor

cromwellryan — Fri, 30 Oct 2009 19:37:56 +0000

One of the tangent patterns associated with isolation or Single Responsibility is the Strategy Pattern. I use Castle Windsor as my IoC of choice and I had hoped there was some black magic built in to make the Strategy Pattern dead simple. Turns out there is and there isn’t.

What is the Strategy Pattern

The strategy pattern is a way of isolating what would often be found in a case statement. The bland example being calculating Sales tax on an Order. Each state and/or country has its own tax calculation and rather than

public void Process(Order order) {
    switch(order.Country) {
        case "USA":
            order.Total = order.Subtotal * .07;
            break;
        case "Canada":
            order.Total = order.Subtotal * .0985;
            break;
    }
 
    // ...
}

you should be breaking each calculation out into different ITaxStrategy implementations and consuming them like so:

public void Process(Order order) {
    var strategy = _taxStrategyFactory.GetStrategyForOrder(order);
 
    var salesTax = strategy.CalculateSalesTax(order);
 
    order.SalesTax = salesTax;
    order.Total = order.SubTotal + order.SalesTax;
}

The question remains, how to eliminate the conditional logic in TaxStrategyFactory determining which strategy is chosen. The solution is to set up a convention for discovering the available strategies and delegating the criteria to the Strategy itself.

Discovery

The concept here is that we don’t have to “hook up” any new Tax Strategy to our Processing mechanism, we just “publish” new ones in a known way and they are picked up simply based on their existence. This is often referred to as Convention Over Configuration. We accomplish this with Castle Windsor with the Fluent Registration API:

container
    .Register(AllTypes
                  .FromAssembly(Assembly.GetExecutingAssembly())
                  .Where(x => x.Name.EndsWith("Strategy"))
                  .WithService.FirstInterface());

This will register all classes found in the executing assembly which have the suffix “Strategy” as implementing the ITaxStrategy interface. The second half of convention based discovery is consuming the ITaxStrategy implementations. We can want to get all of these into the TaxStrategyFactory via a constructor array dependency:

public TaxStrategyFactory(params ITaxStrategy[] taxStrategies)
{
    _taxStrategies = taxStrategies;
}

Unfortunately, Windsor doesn’t support arrays as dependencies by default. Windsor has the concept of Resolvers (a strategy implementation itself) and we are going to have to tell it about the ArrayResolver which knows how to, err, resolve array dependencies:

   1: container
   2:     .Kernel.Resolver.AddSubResolver(new ArrayResolver(container.Kernel));

Cool, so put these all together in our registration code and we get:

container
    .Register(Component
                  .For()
                  .ImplementedBy())
    .Register(Component
                  .For()
                  .ImplementedBy())
    .Register(AllTypes
                  .FromAssembly(Assembly.GetExecutingAssembly())
                  .Where(x => x.Name.EndsWith("Strategy"))
                  .WithService.FirstInterface());

At this point we can kick of the true discovery chain of events through:

var processor = container.Resolve();
 
processor.Process(order);

Delegating Criteria

So in OrderProcessor.Process we are asked the TaxStrategyFactory for the applicable ITaxStrategy implementation:

var strategy = _taxStrategyFactory.GetStrategyForOrder(order);
 
var salesTax = strategy.CalculateSalesTax(order);
 
//...

The question is, how did the factory determine which of the boundless implementations applies? That’s the job of each ITaxStrategy itself. Here’s the implementation of our factory:

class TaxStrategyFactory : ITaxStrategyFactory
{
    private readonly ITaxStrategy[] _taxStrategies;
 
    public TaxStrategyFactory(params ITaxStrategy[] taxStrategies)
    {
        _taxStrategies = taxStrategies;
    }
 
    public ITaxStrategy GetStrategyForOrder(Order order)
    {
        return _taxStrategies.FirstOrDefault(x => x.IsApplicable(order));
    }
}

Notice how the TaxStrategyFactory depends on all of the ITaxStrategy implementations. It then uses the ITaxStrategy.IsApplicable(Order) method as criteria for a FirstOrDefault call. Here’s an example TaxStrategy for any Order with country “USA”:

public class USTaxStrategy : ITaxStrategy
    {
        private static readonly IDictionary<string, double> TaxRates = new Dictionary<string, double>()
                                                                   {
                                                                       {"OH", 7.0},
                                                                       {"MI", 6.25},
                                                                   };
        public double CalculateSalesTax(Order order)
        {
            var rate = TaxRates[order.State];
 
            return (order.SubTotal * (rate / 100));
        }
 
        public bool IsApplicable(Order order)
        {
            return order.Country == "USA";
        }
    }

You can download the sample project that goes along with this here.

Injecting a WCF Channel as Dependency via Windsor

cromwellryan — Tue, 18 Aug 2009 15:45:41 +0000

When working within a closed system which uses WCF and an IoC container you will often find the following pattern:

What happens is the SomeAppService is often, but not always, a very thin wrapper over the WCF Service. If you own both ends of this scenario its often nice to remove the WCF layer between. Maybe you want a different deployment model in some situations such that the WCF service itself can be an in-proc reference. Other times the front end is in a DMZ and the WCF services needs to be inside the corporate firewall. Maybe its just easier to run on a dev machine. Whatever the reason, you don’t always want to be tunneling through WCF. Plus, its just cool to see it work.

To do this, you can use Windsor’s FactorySupportFacility to return a ClientBase.Channel as the dependency instance.

First, you’ll need a little class to expose the ClientBase.Channel since it’s protected:

public class ServiceClient : ClientBase where T : class

{

    public new T Channel

    {

        get { return base.Channel;}

    }

}

Second, add the FactorySupportFacility to your WindsorContainer:

container.AddFacility();

Lastly, register your implementation as either the WCF channel:

container

    .Register(Component.For()

                       .UsingFactoryMethod(() => new ServiceClient().Channel))

…or the actual implementation:

container

    .Register(Component.For()

                  .ImplementedBy())

Ryan Cromwell » Windsor

Strategy Pattern with Castle Windsor

Injecting a WCF Channel as Dependency via Windsor