依赖注入模块依赖注册

Question

我尝试以模块化的方式设计我的应用程序。 我希望能够在任何给定的交换模块。

使用依赖注入模式可以让我做到这一点。 但有些东西一直困扰着我。

在我遇到的大多数代码中，有一个地方将接口链接到所需的接口。 例如在asp.net vnext中，它看起来像这样：

public void ConfigureServices(IServiceCollection services)
{            
    // business-layer
    services.AddTransient<IArticleRepository, ArticleRepository>();

    // data-layer
    services.AddTransient<IDataConnection, DataConnection>();
}

但我不喜欢只有一个地方可以进行注册。 我宁愿让每个模块注册自己的接口/实现：

在我的业务层（模块）

public void ConfigureServices(IServiceCollection services)
{            
    // business-layer
    services.AddTransient<IArticleRepository, ArticleRepository>();           
}

在我的数据层（模块）

public void ConfigureServices(IServiceCollection services)
{            
    // data-layer
    services.AddTransient<IDataConnection, DataConnection>();           
}

做这种事有什么模式或最佳实践吗？ 我可以创建一些接口并在加载时完成此接口的所有实现，但我不确定这是否是执行此操作的最佳方法。

Answer 1

做这种事有什么模式或最佳实践吗？

是的，不是。 有Facade模式 ，您可以为不需要对API进行细粒度控制的客户端提供简化的API。 Facade模式并没有明确涉及依赖注入，但是如果这是一个有意义的事情，你总是可以提供默认的服务组合。 我的文章DI Friendly Library中有更多详细信息。

也就是说，保持API开放非常重要，因此Facade只是您向客户提供的选项之一。 如果您在库中预先构建对象图，并且不为客户端提供任何方法来规避该默认组合，则这样的库将是一个单片黑盒子。 来自依赖注入的所有外部好处都将消失，因为客户端将无法替换或扩展服务。

请遵循DI Friendly Library文章中列出的准则，但一定要避免使用Conforming Container反模式 。

Answer 2

我会说配置你的DI的方式/地点在很大程度上取决于你的DI框架。 一些框架允许您按模块进行配置，其他框架则需要一个全局配置。 在后一种情况下，您可以手动委派给您的子模块（只需将IServiceCollection传递给子模块配置代码）。

关于最佳实践：我很少看到DI的使用有多个生产实现。 通常只有一个生产实现，而DI仅用于在没有样板的情况下将所有内容连接在一起。 但是许多不同的实现（通常是模拟）通常在没有DI框架的情况下通过手动布线进行测试。 如果这也是你的情况那么你的直觉是正确的：拥有扫描整个代码的DI框架，采用默认/唯一的实现并将其作为依赖项注入将是很好的。 如果您的DI框架提供该功能，那么您很幸运。 如果没有，你必须自己实现它