我试图在使用内置DI机制的同时获得与ASP.NET Core 2.1应用程序一致的.NET Framework类库。现在,我创建了一个配置类,并在appsettings.json中添加了适当的部分:
services.Configure<MyConfig>(Configuration.GetSection("MyConfiguration"));
services.AddScoped<MyService>();
在lib类中:
public class MyService
{
private readonly MyConfig _config;
public MyService(IOptions<MyConfig> config)
{
_config = config.Value;
}
}
但是,为了构建该类库,我必须添加Microsoft.Extensions.Options
NuGet包。问题在于,程序包带有很多依赖关系,仅仅为了一个接口而添加的依赖关系似乎太过分了。
因此,最终的问题是,“我是否可以采用另一种方法来配置.NET Framework类库中的DI服务,而该服务并不依赖过多?
答案 0 :(得分:4)
查看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
}
}
答案 1 :(得分:1)
如果您真的可以说是一个问题,我不久前就遇到了这个问题。我认为,当我们看到这样的依赖项列表时,我们都会感到有些震惊。但是,正如@Tseng所提到的,包含一堆额外的微型程序集并没有什么大不了的(通过另一个项目中的引用,它们已经包含在bin
中)。但是我不得不承认,仅在选项界面中就必须包含它们。
我解决问题的方法是解决startup.cs
中的服务依赖关系并相应地调整服务的构造函数:
services.AddTransient<MyService>(Configuration.GetConfiguration("MyConfiguration"));
答案 2 :(得分:0)
如果您不关心IOptions
为您提供的服务,为什么不将IConfiguration
注入您的服务中呢?
public class MyService
{
private readonly IConfiguration _config;
public MyService(IConfiguration config)
{
_config = config;
}
public void DoSomething()
{
var value = _config["SomeKey"];
// doing something
}
}