中间服务提供商的缺点

Question

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

我已经读到我可以构建一个中间服务提供商来做到这一点：

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

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

1. 制作这个"中间服务提供商"有什么缺点？
2. 我的wso2Actions对象是否仍由依赖项注入框架管理？ (好像是后来注射的？
3. 我自己"更新"对象会更好吗？
   • var wso2Actions = new Wso2Actions(); services.AddSingleton<Wso2Actions>(wso2Actions);
   • 我似乎记得读到将实例传递到 DI 引擎会导致较差的生命周期管理。

Answer 1

制作这个"中间服务提供商"有什么缺点？

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

从 Core 3.0 ASP.NET 开始，如果在配置方法中调用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'.

如果您还想阅读，@devNull的评论会提供更多详细信息。

我的 wso2Actions 对象是否仍由依赖注入框架管理？

是的。

(好像是后来注射的？

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

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

我自己"更新"对象会更好吗？

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

如果您愿意使用依赖注入，则有多种选择，具体取决于wso2Actions的用途：

将代码移动到Configure

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

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

使用选项模式

阅读此内容。

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