c# - 为 .NET 库找到正确的组合根

Question

我在这里阅读了关于该论点的各种其他问题，最值得注意的是

Dependency Inject (DI) “friendly” library

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

还有这个article (和其他各种 Material )。

但是，我不清楚在库 (DLL) .NET 项目中将组合根目录放在何处。该项目不属于文章中提到的任何特定类型。在桌面、控制台甚至网络应用程序中，这一点被明确定义。

我目前的做法是包装容器、注册类型并重新公开 Resolve 方法:

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;
}

然后我阻止库使用者创建库的根实例(例如定义内部构造函数)并因此强制使用单例工厂:

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;
}

问题是，是否有更好的方法或更好的模式可用于在库项目中定位组合根？

Answer 1

这取决于您创建的库类型。您的库项目是您自己的解决方案的一部分，还是您的团队、部门甚至组织之外的其他开发人员所依赖的可重用库？

如果它只是解决方案的库项目的一部分，则库项目本身通常不应包含组合根。根据定义，composition root是“(最好)在模块组合在一起的应用程序中的唯一位置”。换句话说，您的解决方案将有一个或多个启动项目(例如 MVC 应用程序、WCF 服务、控制台应用程序)，并且每个启动项目都将获得自己的组合根。下面的层不会获得自己的合成根。

顺便说一句，这并不意味着您不应该阻止组合根内部的代码重复。当包含项目(例如 DAL 和 BLL)的默认连接导致大量重复时，您通常应该将此逻辑提取到另一个项目。您可以通过在其中一个项目(很可能是 BLL)中包含部分注册逻辑并让每个组合根调用该共享逻辑来执行此操作，或者您可以通过为该项目添加一个特殊的“ Bootstrap ”项目来执行此操作，并且引用的项目。这个 Bootstrap 项目将只包含注册逻辑。通过将此逻辑与应用程序程序集分离，您可以防止这些程序集需要对所用依赖注入(inject)库的依赖。但是，如果程序集依赖于此类库，通常不会有问题，只要您确保应用程序逻辑不依赖于容器即可。

对于可重用库，情况通常有所不同。在那种情况下，消费者将使用您的库，但您无法控制他们构建应用程序的方式。您通常希望以消费者可以直接使用的方式提供库，而无需在其组合根中进行各种“复杂”注册。您通常甚至根本不知道它们是否有组合根。

在这种情况下，您通常应该让您的库在没有 DI 容器的情况下工作。你自己不应该依赖这样的容器，因为这会把容器拖进去。如果你确实使用了容器，问问自己为什么你的可重用库使用容器，以及是否必须这样做。也许你这样做是因为你围绕依赖注入(inject)原则设计了所有类型；因为这使测试更容易。不要忘记这是你的问题，而不是你的消费者的问题。作为可重用库的设计者，您应该努力让您的库尽可能地为您的消费者所用。请永远不要假设您的消费者正在使用 DI 容器。即使他们实现依赖注入(inject)，他们也可能会申请 Pure DI而不是 DI 容器。

如果您要构建可重用的库，请查看 this blog来自 Mark Seemann 的帖子。