services.Configure<>()还是services.AddSingleton().Get()？

Question

众所周知，在ASP.NET核心2中有两种获取选项类的方法：

1. 像这样使用services.Configure<>()： services.Configure(Configuration.GetSection("applicationSettings"))；；services.AddOption()
2. 或者像这样使用services.AddSingleton(Configuration.Get())： services.AddSingleton(Configuration.GetSection("applicationSettings") .Get()；

但是，这些不同的方法有哪些优点或缺点？

Answer 1

使用Configure<ApplicationOptions>允许期权模式。选项模式是使用各种配置源配置事物的好方法。在您的示例中，您正在使用ApplicationOptions源代码配置Microsoft.Extensions.Configuration。但是，您也可以同时通过其他来源配置它：

// configure using configuration
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));

// then apply a configuration function
services.Configure<ApplicationOptions>(options =>
{
    // overwrite previous values
    options.Foo = "bar";
});

还有一些其他的方法来调整配置，例如使用post配置，它允许您轻松地组合使用选项，但可能需要建立某些默认值或后置。

选项对象将在使用时进行配置，因此当您调用services.Configure()时，实际上没有配置任何对象。相反，配置是通过DI容器注册的。然后，当选项被解析时，将调用特定类型的所有配置(这允许组合)。这允许选项也支持更新配置；因此，当您在运行时更新appsettings.json时，选项能够接收更新后的值。

为了使用选项，需要注入IOptions<ApplicationOptions> (如果需要更新选项，则需要注入IOptionsSnapshot<ApplicationOptions> )。这是options对象的包装器，它将调用options模式。

另一方面，调用AddSingleton<ApplicationOptions>只是将一个单例实例注册为一个固定值。因此，在DI提供程序中注册的是Configuration.GetSection("applicationSettings").Get<ApplicationOptions>()在该时刻返回的值。

这样做的好处是您不需要使用选项模式；与其将IOptions<ApplicationOptions>注入您的类型，您可以直接依赖于ApplicationOptions。因此，您不需要依赖于选项框架。这对于希望在默认情况下选项模式不可用的不同场景中使用的独立库来说是很好的。

但是，因为这注册了一个固定的实例，所以您也被限制在这些确切的值上。更改配置源后，不能更新这些值，也不能将该配置源与其他配置结合使用。

Answer 2

简短的回答:第一种方式添加了一个Options**，，第二种方式注册了一个简单的单例服务**。

如果可能的话，我总是更喜欢选项模式。

在幕后，Configure<TOptions>()将调用services.AddSingleton<>()注册单个服务来配置选项。然而，要配置选项，我们应该始终使用第一种方式，作为Configure<TOptions>(config) (和其他各种configure<>()方法)将为我们完成所有的繁重工作。：

1. 例如，如果我们想为同一类型存储两个不同的实例，那么如何使用简单的单例服务？事实上，这正是命名选项所做的。
2. 此外，根据对applicationSettings.json的文件更改，很难自动重新加载普通的单例服务。