IOptions<T> 的简化方法
Simplified approach to IOptions<T>
我正在尝试在使用内置 DI 机制时获得与 ASP.NET Core 2.1 应用程序一致的 .NET Framework class 库。现在,我创建了一个配置 class 并将适当的部分添加到 appsettings.json:
services.Configure<MyConfig>(Configuration.GetSection("MyConfiguration"));
services.AddScoped<MyService>();
在 class 库中:
public class MyService
{
private readonly MyConfig _config;
public MyService(IOptions<MyConfig> config)
{
_config = config.Value;
}
}
但是,为了构建这个 classlib,我必须添加 Microsoft.Extensions.Options
NuGet 包。问题是包带有大量的依赖项,仅仅为了一个接口而添加这些依赖项似乎太过分了。
所以,最终的问题是,“我是否可以采用另一种方法来配置位于 .NET Framework class 库中的 DI 服务,该库的依赖性不高?
我刚才遇到了这个问题,如果你真的能称之为问题的话。我想当我们看到这样的依赖列表时,我们都会有点 shell-震惊。但正如@Tseng 所提到的,包含一堆额外的小程序集真的没什么大不了的(它们将根据另一个项目中的引用无论如何已经包含在 bin
中)。但我承认只为选项界面包含它们很烦人。
我是如何解决这个问题的,方法是解决 startup.cs
中的服务依赖关系并相应地调整服务的构造函数:
services.AddTransient<MyService>(Configuration.GetConfiguration("MyConfiguration"));
如果您不关心 IOptions
提供给您的任何东西,为什么不直接将 IConfiguration
注入您的服务?
public class MyService
{
private readonly IConfiguration _config;
public MyService(IConfiguration config)
{
_config = config;
}
public void DoSomething()
{
var value = _config["SomeKey"];
// doing something
}
}
查看 Filip Wojcieszyn 撰写的这篇文章。
https://www.strathweb.com/2016/09/strongly-typed-configuration-in-asp-net-core-without-ioptionst/
您添加扩展方法:
public static class ServiceCollectionExtensions
{
public static TConfig ConfigurePOCO<TConfig>(this IServiceCollection services, IConfiguration configuration) where TConfig : class, new()
{
if (services == null) throw new ArgumentNullException(nameof(services));
if (configuration == null) throw new ArgumentNullException(nameof(configuration));
var config = new TConfig();
configuration.Bind(config);
services.AddSingleton(config);
return config;
}
}
在配置中应用它:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.ConfigurePOCO<MySettings>(Configuration.GetSection("MySettings"));
}
然后使用它:
public class DummyService
{
public DummyService(MySettings settings)
{
//do stuff
}
}
我正在尝试在使用内置 DI 机制时获得与 ASP.NET Core 2.1 应用程序一致的 .NET Framework class 库。现在,我创建了一个配置 class 并将适当的部分添加到 appsettings.json:
services.Configure<MyConfig>(Configuration.GetSection("MyConfiguration"));
services.AddScoped<MyService>();
在 class 库中:
public class MyService
{
private readonly MyConfig _config;
public MyService(IOptions<MyConfig> config)
{
_config = config.Value;
}
}
但是,为了构建这个 classlib,我必须添加 Microsoft.Extensions.Options
NuGet 包。问题是包带有大量的依赖项,仅仅为了一个接口而添加这些依赖项似乎太过分了。
所以,最终的问题是,“我是否可以采用另一种方法来配置位于 .NET Framework class 库中的 DI 服务,该库的依赖性不高?
我刚才遇到了这个问题,如果你真的能称之为问题的话。我想当我们看到这样的依赖列表时,我们都会有点 shell-震惊。但正如@Tseng 所提到的,包含一堆额外的小程序集真的没什么大不了的(它们将根据另一个项目中的引用无论如何已经包含在 bin
中)。但我承认只为选项界面包含它们很烦人。
我是如何解决这个问题的,方法是解决 startup.cs
中的服务依赖关系并相应地调整服务的构造函数:
services.AddTransient<MyService>(Configuration.GetConfiguration("MyConfiguration"));
如果您不关心 IOptions
提供给您的任何东西,为什么不直接将 IConfiguration
注入您的服务?
public class MyService
{
private readonly IConfiguration _config;
public MyService(IConfiguration config)
{
_config = config;
}
public void DoSomething()
{
var value = _config["SomeKey"];
// doing something
}
}
查看 Filip Wojcieszyn 撰写的这篇文章。
https://www.strathweb.com/2016/09/strongly-typed-configuration-in-asp-net-core-without-ioptionst/
您添加扩展方法:
public static class ServiceCollectionExtensions
{
public static TConfig ConfigurePOCO<TConfig>(this IServiceCollection services, IConfiguration configuration) where TConfig : class, new()
{
if (services == null) throw new ArgumentNullException(nameof(services));
if (configuration == null) throw new ArgumentNullException(nameof(configuration));
var config = new TConfig();
configuration.Bind(config);
services.AddSingleton(config);
return config;
}
}
在配置中应用它:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.ConfigurePOCO<MySettings>(Configuration.GetSection("MySettings"));
}
然后使用它:
public class DummyService
{
public DummyService(MySettings settings)
{
//do stuff
}
}