Question

所以，在决定我的项目的架构时，我一直在阅读有关CQRS的内容，并找到了this库。它不是很复杂或者类似的东西，但有一件事引起了我的注意：here正在注入ISeviceProvider而here正在使用它。所以，我的问题是：直接用服务提供者构建对象是一个好习惯，这意味着没有注入？如果只有在运行时只知道对象的类型，那么构建对象的方法是否正确？

Answer 1

如果您在运行时知道类型，则使用IServiceProvider基本上是DI的唯一选项（例如，通过MVC组件中的RequestServices）。

只有在编译时知道类型时，构造函数注入才可行，因为必须在构造函数中指定对象的类型。

根据需要，您还可以在ConfigureServices()中注册实现工厂，并根据运行时信息提供某些接口的不同实例。

编辑：ASP.NET Core中实现工厂的一个示例：

services.AddTransient<IDataService, DataService>((ctx) =>
{
    IOtherService svc = ctx.GetService<IOtherService>();
    //IOtherService svc = ctx.GetRequiredService<IOtherService>();
    return new DataService(svc);
});

此处DataService取决于IOtherService，因此它会从GetService<T>()的服务提供商处获取。您可以使用GetRequiredService<T>()来强制执行此要求。

Answer 2

使用服务提供者直接构建对象是一种好习惯，这意味着没有注入？

这取决于。将通用解析程序注入类而不是特定依赖项是一种通常称为Service Locator的模式，它被认为是an anti-pattern。

然而，使用此IServiceProvider是否是服务定位器反模式的实现取决于它的使用方式，如here所述：

封装在Composition Root中的DI容器不是服务定位器 - 它是基础架构组件。

我们可以认为这个CommandProcessor是一个基础架构，只要它是＆＃34;封装在一个组合根＆＃34;。

ASP.NET Core并注入IServiceProvider

2 个答案: