.NET CORE 依赖注入 实践总结
标签：ted section conf bsp 服务 单元 线程 默认 tar
知识点回顾
- 依赖包。 Microsoft.Extensions.DependencyInjection.Abstractions
- 核心对象和方法。
-
IServiceCollection。注入对象的容器。注意它只存储对象的元数据，并不保存实例对象。
-
IServiceProvider。注入对象的提供者。它负责提供具体的对象实例。在架构中，IServiceProvider有2种身份，一种是Root ServiceProvider，由service.BuildServiceProvider()创建，生命周期贯穿整个应用程序，AddSingleton对象保存在这里。另外一种则是普通IServiceProvider，由IServiceScope创建，生命周期即为AddScoped的生命周期。AddScope 的对象保存在这里。普通ServiceProvider由Root ServiceProvider创建的IServiceScope创建。
-
IServiceScope。表某一个生命周期范围。由ServiceProvider.CreateScope()创建。
-
注入方式，知识点一。
- 注入功能默认在Startup类中的ConfigureServices方法中。
-
注入方式，知识点二。支持以下三种方式
- AddScoped。生命周期为Scoped类型。例如在web框架中，即表示一次Request请求范围内。
- AddSingleton。单例，应用程序全局使用同一个实例。
- AddTransient。即时的，即对象每次使用都会重新实例化。
-
注入方式，知识点三。提供多种注入技巧，以Transient为例
- 实例注入。AddTransient(this IServiceCollection services)。
- 泛型注入。AddTransient(this IServiceCollection services)。
- 工厂注入。AddTransient(this IServiceCollection services, Func implementationFactory)。
- TryAddXXX。仅当XXX尚未注册实现时，注册该服务。此方法用来避免在容器中注册一个实例的两个副本。
- 获取实例的方法 GetService和GetRequiredService的区别，前置如果service不存在会返回NULL，后者会直接抛出异常。根据需要选择GetRequiredService，可能会让你的代码变得简洁一点。
WHY 依赖注入
这里只谈益处。
- 使用接口或基类抽象化依赖关系实现，明确各个类之间的依赖关系。
- 生命周期的统一管理，尤其对于某些类被多处依赖，关系会变得分散难以管理，依赖注入容器可以解决这点。
- 非常利于单元测试。
最佳实践
部分来自官方文档的一些建议
- 对于需要注入为单例的实例，不要依赖Scoped实例。会触发 .NET CORE作用域验证失败。
- 不要从Root IServiceProvider解析有作用域的实例，这样会导致该作用域的实例变成单一实例。同样会触发作用域验证失败。
- 对于Asp.Net Core，尽量通过构造函数而不是HttpContext.RequestServices获取实例，这样更易于单元测试。
- 需要对某个组件服务或是一些服务集合（包括其依赖注入时），使用约定的 Add{SERVICE_NAME} 扩展方法来注册该服务所需的所有服务。
- 若必须要从IServiceProvider中解析实例（如在单元测试中），请通过using (var scope = ServiceProvider.CreateScope()){ }方式创建作用域来获取实例。
- 代码中避免设计有状态的、静态类和成员。可以考虑设计注入为单一实例。
- 代码中避免在服务中直接实例化以来类。尽量采用依赖注入的方式
- 注意以下两种方式注入的区别，后者的实例化不是服务容器创建的，所有容器不会处理实例的Dispose !!
public class Service1 : IDisposable {}
public class Service2 : IDisposable {}
//方式一
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton();
services.AddSingleton(sp => new Service2());
}
//方式二
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton(new Service1());
services.AddSingleton(new Service2());
}
- 延伸上一点，对于复杂对象的创建，尽量采用提供的工厂注入方式。注意工厂注入的参数是IServiceProvider，可以通过它获取你需要的实例对象。
- 继续延伸上一点，不要在ConfigureServices方法中 通过collection.BuildServiceProvider()来获取IServiceProvider。这个创建的是一个Root IServiceProvider。单例会实例化一次，然后ConfigureServices方法结束后框架会再次调用collection.BuildServiceProvider()，单例又会重新实例化一次。
- 不支持基于async/await和Task的服务解析。
- 避免在容器中直接存储数据和配置。配置应使用NET CORE的选项模型。
- 避免使用服务定位器模式。例如直接注入IServiceProvider来获取多个需要的服务。PS，如果你的服务依赖项过多，应该考虑分割成几个小功能服务了。
引入第三方IOC框架
.NET CORE 3.x版本后，引入第三方IOC框架的方式变更了，这里不再贴出2.x的方式。以Autofac框架为例。
Program.cs
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.UseServiceProviderFactory(new AutofacServiceProviderFactory())
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup()
.ConfigureLogging((hostingContext, logging) =>
{
logging.ClearProviders();
logging.AddConsole();
logging.AddNLog();
});
});
Startup.cs
//原来的 ConfigureServices保留，也可以使用原来的框架继续注入
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
services.AddMemoryCache();
services.Configurestring>>(Configuration.GetSection("BlackPhoneList"));
services.Configurestring, string>>(Configuration.GetSection("BusinessMessages"));
}
//增加ConfigureContainer(ContainerBuilder builder) 方式，使用Autofac框架注入
public void ConfigureContainer(ContainerBuilder builder)
{
builder.RegisterType().Named("PHONE_BLACKLIST").SingleInstance();
builder.RegisterType().Named("PHONE_PERDAYCOUNT").SingleInstance();
builder.RegisterType().Named("UNIQUEID_PERDAYCOUNT").SingleInstance();
//可遍历类型注入，注意 只支持IEnumerable\IList\ICollection 类型
builder.RegisterType().As().SingleInstance();
}
3.x 主要是在IServiceCollection和IServiceProvider之间增加了一个 ContainerBuilder 容器适配，使得第三方IOC框架引入更加合理了。具体实现原理可以网上源码查找。
特别关注-线程安全
- 创建线程安全的单一实例服务。 如果单例服务依赖于一个Transient服务，那么Transient服务可能也需要线程安全，具体取决于单例使用它的方式。
- 工厂注入方式的Func不需要是线程安全的，框架保证它由单个线程调用一次。
.NET CORE 依赖注入 实践总结
标签：ted section conf bsp 服务 单元 线程 默认 tar
原文地址：https://www.cnblogs.com/gt1987/p/12973001.html
评论