DI 组合根：它如何确保编译时分辨率检查

Question

我已经阅读了 Mark Seeman 关于依赖注入的几篇文章，特别是避免使用服务定位器模式的原因：

• Service Locator is an Anti-Pattern
• Service Locator violates encapsulation
• Service Locator violates SOLID

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

var orderProcessor = new OrderProcessor();

// following line fails at compile time if you 
// forget to register all necessary services - and
// you don't have a way of knowing which services it needs

orderProcessor.Process(someOrder);

但这意味着，Composition Root 不仅必须在启动时解决 所有 依赖关系，还要实际实例化整个对象图，否则我们仍然不知道所有必要的依赖关系都已注册：

private static void Main(string[] args)
{
    var container = new WindsorContainer();
    container.Kernel.Resolver.AddSubResolver(
        new CollectionResolver(container.Kernel));

    // Register
    container.Register(
        Component.For<IParser>()
            .ImplementedBy<WineInformationParser>(),
        Component.For<IParser>()
            .ImplementedBy<HelpParser>(),
        Component.For<IParseService>()
            .ImplementedBy<CoalescingParserSelector>(),
        Component.For<IWineRepository>()
            .ImplementedBy<SqlWineRepository>(),
        Component.For<IMessageWriter>()
            .ImplementedBy<ConsoleMessageWriter>());

    // Everything must be resolved AND instantiated here
    var ps = container.Resolve<IParseService>();
    ps.Parse(args).CreateCommand().Execute();

    // Release
    container.Release(ps);
    container.Dispose();
}

这在实际应用中的可行性如何？这真的意味着你不应该在构造函数之外的任何地方实例化任何东西吗？

（附加信息）

假设您有一项服务应该处理来自多种测量设备（不同的连接类型、协议或同一协议的不同版本）的传入连接。每当您获得新连接时，服务都应该构建一个“管道”，从输入端口，通过 fifo 缓冲区，到特定于该设备类型的许多解析器，以多个消费者结束各种解析的消息。

预先组合这些对象图在应用程序启动时似乎是不可能的。即使它可以延迟，我仍然看不到如何获得早期（-er）指示对象图构造将失败。

这似乎是main problem with service locators，我不知道如何避免它：

简而言之，Service Locator 的问题在于它隐藏了类的依赖关系，从而导致运行时错误而不是编译时错误，并且使代码更难维护，因为不清楚何时会出现引入重大更改。

Answer 1

但这意味着Composition Root不仅要在启动时解决所有依赖关系，还要实际实例化整个对象图

如果您应用 Pure DI（即应用依赖注入模式，但没有 DI 容器），您将获得开箱即用的编译时支持。使用 DI 容器，您必须在运行时执行这些检查，但这并不意味着您必须在启动期间执行此操作，尽管我会说这是首选。所以如果在启动时检查容器的配置不会导致性能问题，你应该这样做。否则，您可以将此验证步骤移至单元测试。

这在实际应用中的可行性如何？

这是完全可行的。我构建的大型应用程序通常在容器中注册了数百到上千个服务，并且我总是验证（和diagnose）我的容器的配置，这可以防止许多常见的配置错误，这些错误很容易犯，而且很难追踪。

这真的意味着你不应该在构造函数之外的任何地方实例化任何东西吗？

您的组合根负责创建您的服务；这本身并不意味着所有服务都应该在启动期间创建，因为您可以将部分对象图的创建延迟到运行时。然而，我首选的工作方式是使所有注册的服务成为单例（应用程序期间的一个实例）。这使得在应用程序启动期间创建所有服务变得非常容易（且成本低廉），并迫使您进入更严格的模型，从而更快地弹出 SOLID 违规和其他 DI 不良做法。