Question

I’ve been experimenting with using named delegates instead of single-method interfaces. This has some advantages for code size, as we can go from (some linebreaks removed so as not to overstate the case):

public interface IProductSource
{
    IEnumerable<Product> GetProducts();
}
public class DataContextProductSource : IProductSource
{
    private readonly DataContext _DataContext;
    public DataContextProductSource(DataContext dataContext)
    {
        if (dataContext == null) throw new ArgumentNullException("dataContext");
        _DataContext = dataContext;
    }
    public IEnumerable<Product> GetProducts()
    {
        return _DataContext.Products.AsEnumerable();
    }
}

to:

public delegate IEnumerable<Product> DGetProducts();
public static class DataContextFunctions
{
    public DGetProducts GetProducts(DataContext dataContext)
    {
        if (dataContext == null) throw new ArgumentNullException("dataContext");
        return () => dataContext.Products.AsEnumerable();
    }
}

This is basically taking advantage of the fact that once you go far enough with dependency injection, a lot of classes become little more than closures. Those classes can be replaced with functions that return lambdas. Entire sets of related functions (that don’t need to encapsulate any mutable state, but would have been expressed using classes in “standard” dependency injection), can then be rolled up into a static class (or “module” in VB parlance).

This is all well and good, but I’m having trouble finding the best way to register these static methods with Castle Windsor. Methods with no dependencies are easy:

Component.For<DGetIntegers>().Instance(Integers.GetOneToTen)

But our DataContextFunctions.GetProducts from above has some dependencies. The best way I’ve found to register this is:

Component.For<DGetProducts>().UsingFactoryMethod(
    kernel => DataContextFunctions.GetProducts(kernel.Resolve<DataContext>())

This can get quite verbose, and obviously having to ask the kernel directly for each dependency kind of defeats the point a bit. It seems to me that all the static information that a container should need is available, so it should be possible to do this.

The question is, does Castle Windsor (or any other container) have a simple way to do this that I’ve missed, or are there technical problems that arise, or is it just too niche a use case to have been included?

Answer 1

That’s an interesting approach. I think you could get this working quite easily with a custom activator.