Locate the correct composition root for a .NET library

Question

I've read various other question here on the argument, most notably

Dependency Inject (DI) “friendly” library

Ioc/DI - Why do I have to reference all layers/assemblies in entry application?

and this article (and other various material).

However it's not clear to me where to place composition root in library (DLL) .NET project. The project does not belong to any specific type mentioned in the article. In desktop, console or even web application this point is instead clearly defined.

My current approach is to wrap the container, register types and re-expose the Resolve method:

class DefaultBootstrapper : IBootstrapper {
  public Bootstrapper() {
    _container = new XXXContainer();
    RegisterTypes(_container);
  }

  public T Resolve<T>() where T : class {
    return _container.Resolve<T>();
  }

  // + other _container.Resolve() overloads

  private readonly XXXContainer _container;
}

Then I prevent library consumers to create root instances of the library (e.g. defining internal constructors) and hence forcing the use of a singleton factory:

class XYZFactory {
  static XYZFactory() {}

  private XYZFactory(IBootstrapper bootstrapper) {
    _bootstrapper = bootstrapper;
  }

  public static XYZFactory Instance {
    get { return Singleton; }
  }

  public ABCType CreateABCType(string param1) {
    return _bootstrapper.Resolve<ABCType>(param1, _bootstrapper.Resolve<Dependency1>); 
  }

  private static readonly XYZFactory Singleton = XYZFactory(new DefaultBootstrapper);
  private readonly IBootstrapper _bootstrapper;
}

The question is, there's a better approach or a better pattern to employ for locate the composition root in a library project?

Inapproachable

Answer 1

It depends on the type of library you are creating. Is your library project part of your own solution, or is it a reusable library that other developers depend upon outside your team, department, or perhaps even organization?

In the case of it being just a library project part of a solution, the library project should itself typically not contain a composition root. By definition, the composition root is a "(preferably) unique location in an application where modules are composed together". In other words, your solution would have one or multiple start-up projects (such as a MVC application, WCF service, console app), and each start-up project would get its own composition root. Layers below would not get their own composition root.

This btw does not mean that you should not prevent code duplication inside the composition roots. When there is a lot of duplication caused by a default wiring for included projects (such as DAL and BLL), you should typically extract this logic to another project. You can either do this by including part of the registration logic inside one of the projects (most likely the BLL) and let each composition root call that shared logic, or you can do this by adding a special 'bootstrapper' project for that project and the referenced projects. This bootstrapper project will only contain the registration logic. By separating this logic from the application assemblies you prevent those assemblies from needing a dependency on the used dependency injection library. It is however usually not a problem if a assembly takes a dependency on such library, as long as you make sure the application logic keeps free from taking dependencies on the container.

For reusable libraries things are usually different. In that case consumers will use your library, but you have no control over how they structure their application. You often want to supply the library in a way that it can directly be consumed by consumers, without having to do all kinds of 'complex' registration in their composition root. You often don't even know if they have a composition root at all.

In that case you should typically make your library working without a DI container. You should yourself not take a dependency on such a container, because this would drag the container in. If you do use a container, question yourself why your reusable library uses a container, and if this has to be. Perhaps you do because you designed all types around the dependency injection principle; because this makes testing easier. Don't forget that this is your problem, not the problem of your consumers. As a reusable library designer, you should hard in getting your library as usable as possible for your consumers. Please do never assume your consumers are using a DI Container. Even if they practice Dependency Injection, they might apply Pure DI rather than a DI Container.

In case you are building a reusable library, take a look at this blog post from Mark Seemann.

Falsity

I'm sorry I can't still vote up (but I will on 15+). When I was interested just in the framework scenario, when container (if present) would have hidden from public interface, you presented me a lot of different ones. Can I ask you a reference to deepen the argument (blog article or book) about the poor-man-injection that in case of reusable libraries became useful? Thanks, again – Inapproachable

I can't reference any specific work to backup my arguments, but in general Mark Seemann's book "Dependency Injection in .NET" is the best reference about DI, although it mainly talks about the LOB scenario. You can look at the source code Microsoft Enterprise Library. Note the the E.L. takes a hard dependency on Unity, and is something I think you should try to prevent when writing a reusable library. – Falsity

This sounds as confirmation that Dep. Injection .NET is a required reading to me. I'll delve further into this argument, but, returning to reusable library question, I think that poor-man-injection in this case (that as you say it's an exceptional one) is the right design choice. It enables unit testing (through the InternalsVisibleTo attribute) and for me this is a central requirement. – Inapproachable