dependency-injection - 依赖注入(inject)模块化依赖注册

Question

我尝试始终以模块化方式设计我的应用程序。我希望能够随时交换模块。

使用依赖注入(inject)模式可以让我做到这一点。但是有一些事情一直困扰着我。

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

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

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

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

在我的业务层(模块)

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

在我的数据层(模块)

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

是否有任何模式或最佳实践来做这种事情？我可以创建一些接口(interface)并在加载时通​​过该接口(interface)的所有实现，但我不确定这是否是最好的方法。

Answer 1

Is there any pattern, or best-practice to do this kind of things?

是和不是。有 Facade pattern您为不需要对 API 进行细粒度控制的客户端提供简化的 API。 Facade 模式并没有明确关注依赖注入(inject)，但如果这是有意义的事情，您总是可以提供默认的服务组合。更多细节在我的文章 DI Friendly Library .

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

请遵循 DI Friendly Library 中概述的指南。文章，但一定要避免 Conforming Container anti-pattern .