Question

我计划将各种工具箱项目转换为各种NuGet软件包。这个想法是使用services.AddMvc()风格的依赖项注入（我不确定它叫什么）。我们称之为 ConfigureServices模式。

简而言之，该想法是允许如下使用库：

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    // ...
    services.AddSomeLibrary(/* potential configuration here */);
    // ...
}
public void Configure(IApplicationBuilder application)
{
    // ...
    application.UseSomeLibrary(); // If necessary
    // ...
}

问题1：是否存在将连接字符串之类的东西用作AddSomeLibrary()扩展方法的首选方法？

当OuterLibrary依赖于InnerLibrary时，还会遇到另一个挑战，而这又需要一些配置-假设是一个连接字符串。

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    // AddOuterLibrary's implementation will call AddInnerLibrary(...)
    // Are we going to ask for InnerLibrary's configuration input here?
    services.AddOuterLibrary(...);
}

问题2：：AddOuterLibrary()应该如何获得调用AddInnerLibrary()所需的配置输入？

特别是，我认为某些配置选项在不知道它们配置哪个子库的情况下可能看起来非常模糊。

也许答案可以使用外部库的示例，具体取决于日志记录库。日志记录库将需要使用一种特定类型的记录器（一种记录器记录到ElasticSearch，一种记录器记录到MySql，...）和一个连接字符串（仅对特定的特定记录器类型有意义）。

然后，我们的应用程序甚至可能还会由第三个库直接使用InnerLibrary。

问题3：：当一个库添加另一个库时，它应该使用主服务集合，即使用与应用程序其余部分相同的容器实例，还是应该使用自己的单独容器实例？

我想如果我们使用主容器，那么以下是正确的：

我们保持控件的反转，甚至可以对库的依赖项进行合成根控制。
要使包含的库（例如）使用应用程序自身逻辑之外的另一个日志记录端点变得很困难。（愚蠢的例子，但可能还有更多相关的例子。）
我们正在配置日志记录可能会变得晦涩难懂，即使它看起来像只是在配置一个库一样，它也会影响整个应用程序。

.NET Core DI：使用库配置库

0 个答案: