是否有与 IServiceCollection 的“TryAdd”方法等价的方法用于 IOptions<T> 模式？答案

【问题标题】：Is there an equivalent to IServiceCollection's "TryAdd" methods for use with the IOptions<T> pattern?是否有与 IServiceCollection 的“TryAdd”方法等价的方法用于 IOptions<T> 模式？
【发布时间】：2020-04-05 05:05:50
【问题描述】：

我发现 .NET Core IOptions 模式（如以下语法所示）非常有用。

services.Configure<MySettings>(configuration.GetSection("MySettings"));

我还发现 TryAdd 方法有助于防止重复服务注册，如下所示：

services.TryAddTransient<IMyService, MyService>();

我想知道是否有人知道使用 IOptions 完成相同事情的任何技术，或者是否可能在框架中内置了重复注册保护。换句话说，我正在寻找这样的东西：

services.TryConfigure<MySettings>(configuration.GetSection("MySettings"));

【问题讨论】：

TryAdd 谈到了对比赛条件的担忧。或者通常是本课程的多任务处理重点。这可以包括从多个程序调用的函数（就像大多数 Windows API 函数的情况一样 - 除非您有一个锁定机制。您可以在并发集合、通道（修改后的队列）和类似情况中找到它。
Dictionary<TKey, TValue> 上的任何 TryParse 和 TryAdd 都不是这样。特别是在键值结构上，它是尝试添加重复键时抛出异常的替代方法。
IServiceCollection TryAdd 方法的重点不是处理并发问题，容器不会在重复键上抛出异常。我假设 OP 正在尝试将“合理的默认”IOptions 注册添加为框架的一部分，并希望允许框架用户有选择地替换该注册。有关该模式的说明，请参阅 here。

标签： c# asp.net-core dependency-injection .net-core

【解决方案1】：

实际上，我也有同样的“问题”。我是这样解决的：

if (!services.Any(d => d.ServiceType == typeof(IConfigureOptions<MySettings>)))
{
    services.Configure<MySettings>(configSection);
}

此解决方案基于on Microsoft TryAdd code。

提示：您可以为其创建扩展方法。

【讨论】：

为什么是吓人的引号？也许这不是一个严重的问题，但我不认为我建议它是。我只是好奇是否有内置技术，或者有其他不编写我自己的扩展方法的原因（如果我没记错的话，我就是这样处理它的）。
对不起，我无意抱怨或试图用可怕的引语贬低你的问题。我不是英语母语。这是一个有效的问题，我也有同样的问题，这就是为什么我发现你的问题我无法找到原生扩展
啊好吧，那就无视这个吧！这看起来是正确的，所以我会接受答案。 “TOptions”应该是“MySettings”吗？我现在不在我的机器上进行验证。
是的，你说得对，我忘了改。更新了谢谢:)