IOptions注入 [英] IOptions Injection

查看:359
本文介绍了IOptions注入的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我看来,让域服务需要IOptions实例传递其配置是一个坏主意.现在,我将其他(不必要的?)依赖项拉入了库中.我已经在网上看到很多注入IOptions的示例,但是我看不到它带来的额外好处.

It seems to me that it's a bad idea to have a domain service require an instance of IOptions to pass it configuration. Now I've got pull additional (unnecessary?) dependencies into the library. I've seen lots of examples of injecting IOptions all over the web, but I fail to see the added benefit of it.

为什么不将实际的POCO注入服务中?

Why not just inject that actual POCO into the service?

    services.AddTransient<IConnectionResolver>(x =>
    {
        var appSettings = x.GetService<IOptions<AppSettings>>();

        return new ConnectionResolver(appSettings.Value);
    });

或者甚至使用这种机制:

Or even use this mechanism:

        AppSettings appSettings = new AppSettings();

        Configuration.GetSection("AppSettings").Bind(appSettings);

        services.AddTransient<IConnectionResolver>(x =>
        {      
             return new ConnectionResolver(appSettings.SomeValue);
        });

设置的用途:

public class MyConnectionResolver 
{
     // Why this?
     public MyConnectionResolver(IOptions<AppSettings> appSettings)
     {
           ... 
     }

     // Why not this?
     public MyConnectionResolver(AppSettings appSettings)
     {
           ... 
     }

     // Or this
     public MyConnectionResolver(IAppSettings appSettings)
     {
           ... 
     }
}

为什么还有其他依赖项? IOptions会给我买什么,而不是像以前那样用旧的方式注入东西?

Why the additional dependencies? What does IOptions buy me instead of the old school way of injecting stuff?

推荐答案

从技术上讲,没有什么可以阻止您向ASP.NET Core的依赖注入注册POCO类或创建包装类并从中返回IOption<T>.Value.

Technically nothing prevents you from registering your POCO classes with ASP.NET Core's Dependency Injection or create a wrapper class and return the IOption<T>.Value from it.

但是您将失去Options软件包的高级功能,即在源发生更改时自动更新它们,如您在源

But you will lose the advanced features of the Options package, namely to get them updated automatically when the source changes as you can see in the source here.

如果通过services.Configure<AppSettings>(Configuration.GetSection("AppSettings"));注册选项,它将读取来自appsettings.json的设置并将其绑定到模型中,并跟踪其更改.编辑appsettings.json后,它将与新值重新绑定模型,如

As you can see in that code example, if you register your options via services.Configure<AppSettings>(Configuration.GetSection("AppSettings")); it will read and bind the settings from appsettings.json into the model and additionally track it for changes. When appsettings.json is edited, and will rebind the model with the new values as seen here.

如果您想将一些基础结构泄漏到您的域中,或者传递Microsoft.Extension.Options软件包提供的额外功能,那么您当然需要自己做决定.这是一个非常小的程序包,与ASP.NET Core无关,因此可以独立使用.

Of course you need to decide for yourself, if you want to leak a bit of infrastructure into your domain or pass on the extra features offered by the Microsoft.Extension.Options package. It's a pretty small package which is not tied to ASP.NET Core, so it can be used independent of it.

Microsoft.Extension.Options软件包足够小,仅包含抽象和IConfiguration的具体services.Configure重载(与配置的获取方式,命令行,json,环境,天蓝色密钥库密切相关)等)是一个单独的程序包.

The Microsoft.Extension.Options package is small enough that it only contains abstractions and the concrete services.Configure overload which for IConfiguration (which is closer tied to how the configuration is obtained, command line, json, environment, azure key vault, etc.) is a separate package.

因此,总而言之,它对基础结构"的依赖性非常有限.

So all in all, its dependencies on "infrastructure" is pretty limited.

这篇关于IOptions注入的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆