目前关于依赖注入的文档缺乏 - 依赖注入。使用内置DI与现有解决方案(如Ninject,Autofac,StructureMap)相比的优缺点是什么?默认的依赖注入当前存在哪些限制(如果有)?
目前关于依赖注入的文档缺乏 - 依赖注入。使用内置DI与现有解决方案(如Ninject,Autofac,StructureMap)相比的优缺点是什么?默认的依赖注入当前存在哪些限制(如果有)?
ValidateOnBuild
的功能,但它唯一的作用是检查是否可以满足所有注册的所有依赖项。Service1
和Service2
都依赖于ILogger
时,您可能希望将Service1
注入为NullLogger
,将Service2
注入为FileLogger
,或者您希望将Service1
注入为Logger < Service1 >
,将Service2
注入为Logger < Service2 >
。这里解释一下:
Alpha 版本有以下限制:
如果你没有写非常复杂的产品,那么默认的 DI 容器就足够了。在其他情况下,你可以尝试已经提到的具有高级功能的库。
我的建议是从默认容器开始,并在(如果)遇到无法处理的情况时更改实现方式。
Additionally, can someone help me to understand what is the difference between these registrations?
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IService, Service>(); services.AddScoped<IService, Service>(); services.AddSingleton<IService, Service>(); services.AddInstance(service); }
https://stackoverflow.com/revisions/30681477/8
来源: http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles, http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency-injection-in-6-steps/
为了更好地解释为什么它被称为作用域,考虑以下代码:
// app startup
var services = new ServiceCollection();
services.AddScoped<IService, Service>();
var startupServices = services.BuildServiceProvider();
// request init
var requestServices = statupServices.CreateScope().ServiceProvider;
RTM更新
请注意,在Asp.Net Core RTM文档中,Instance被移除了。Instance基本上与Singleton相同,但它们具有不同的初始化语义(Singleton是惰性加载)。但现在没有AddInstance API,只有AddSignleton可以接受已创建的实例。