中间服务提供商的缺点

Question

我正在尝试在 ConfigureServices 方法期间访问自定义 class 的实例。

我我可以构建一个中间服务提供商来执行此操作：

public void ConfigureServices(IServiceCollection services)
{
    // .... Other Stuff ....
    services.AddSingleton<Wso2Actions>();
    var serviceProvider = services.BuildServiceProvider();
    var wso2Actions = serviceProvider.GetService<Wso2Actions>();
    // .... Other stuff ....

关于这项技术我有 3 个问题：

这样做有什么缺点 "Intermediate Service Provider"？
我的 wso2Actions 对象是否仍由依赖注入框架管理？（好像是后来注射的？）
我自己 "newing" 把这个物体弄起来会更好吗？
- var wso2Actions = new Wso2Actions(); services.AddSingleton<Wso2Actions>(wso2Actions);
- 我似乎记得读过将实例传递到 DI 引擎会导致较差的生命周期管理。

Answer 1

What are the drawbacks to making this "Intermediate Service Provider"?

您最终可能会在应用程序中拥有多个容器。这里的主要缺点之一是您的单例服务可以存在于多个容器中。即单例服务的多个实例。

从 ASP.NET Core 3.0 开始，如果您在配置方法中调用 BuildServiceProvider，您会看到警告：

Calling 'BuildServiceProvider' from application code results in an additional copy of
singleton services being created. Consider alternatives such as dependency injecting 
services as parameters to 'Configure'.

如果你也想读的话会更详细。

Will my wso2Actions object still be managed by the dependency injection framework?

是的。

(As if it had been injected later on?)

没有。如果稍后将 wso2Actions 注入到控制器中，则用于解析实例的容器就是 ASP.NET Core 使用的容器。而在您的 ConfigureServices 中，实例是使用您的代码构建的瞬态容器解析的。

请注意，两个容器都是独立的，可能包含不同的服务注册。

Would I be better off just "newing" up the object myself?

如果你愿意使用new，那为什么不呢

如果你愿意使用依赖注入，根据wso2Actions的用途，有多种选择：

将代码移至 Configure

显然，您可以将代码移动到 Configure，它会在构建容器后调用：

var wso2Actions = app.ApplicationServices.GetService<Wso2Actions>();

使用选项模式

阅读this。

services.AddOptions<MyOptions>("optionalName")
    .Configure<Service1, Service2, Service3, Service4, Service5>(
        (o, s, s2, s3, s4, s5) => 
            o.Property = DoSomethingWith(s, s2, s3, s4, s5));

中间服务提供商的缺点

Intermediate Service Provider Drawbacks

c#

dependency-injection

asp.net-core

asp.net-core-3.1