一、.Net Core 依赖注入详解及Autofac使用

2021年7月7日 2点热度 0条评论 来源: 懒懒的佩奇

.NET中的依赖注入实际上帮助我们解耦了我们的代码,是控制反转和依赖反转原则的具体实现。

.Net Core的依赖注入的好处:

1. application 更稳定,容易维护和演化;

2. 实现细节的变化,不需要到处更改,在声明的时候进行替换即可;

3. 测试更容易,更好地mock依赖的service等。

4. 高级的模块或者服务不应该依赖于具体的实现,而是抽象。

 

服务的生命周期

1. Singleton: 应用程序运行期间是唯一的。需要考虑线程安全性,效率高

2. Scoped: 每个请求期间,实例唯一;需要考虑线程安全性,效率

3. Transient: 每次需要的时候实例化,不需要考虑线程安全,效率相对较低

关于服务的声明周期: 一个服务不应该依赖于比它生命周期短的服务。

我们通过 AddTransient,AddSingleton, AddScoped  可以完成大多数的场景需要;

serviceDescriptor 对象一般是隐含在直接调用的AddSingleton/AddTransient/AddScoped中的。

var serviceDescriptor = new ServiceDescriptor.Singleton<IServiceA, ServiceA>();

services.Add(serviceDescriptor);

=== 等价于


services.AddSingleto<IServiceA, ServiceA>();

 

ServiceCollection 复杂场景的使用

1. 同一个接口的不同实现,TryAdd

DI container 会按照注入顺序去resolve需要的接口实现,如下:

services.AddSingleton<IWeatherForecaster, WeatherForecaster>();
services.AddSingleton<IWeatherForecaster, AmazingWeatherForecaster>();
-------

public ServiceA(private IWeatherForecaster _weather) {
}
_weather 实例化出来的 class 是typeof(AmazingWeatherForecaste), 按照我们在 ConfigureServices 中声明的顺序,最后一个起作用;


对ServiceCollection 的理解:serviceCollection是一个集合,里面包含了webhost加入的一些内置 ServiceDescriptors, 以及我们在configureservices 中声明的注入。
因此,本质上,我们对于这个servicecollection里面的操作可以参照集合的操作。

2. 取代接口的实现和移除接口的所有实现
Replace: 取代servicetype 的第一个实现,示例如下。
services.AddSingleton<IWeatherForecaster, WeatherForecaster>();
services.Replace(ServiceDescriptor.Singleton<IWeatherForecaster, AmazingWeatherForecaster>());

通过如上代码,我们在 service collection中只能找到  IWeatherForecaster 实现 只有 AmazingWeatherForecaster, 因为AmazingWeatherForecaster 取代了  WeatherForecaster。

 RemoveAll: 在service collection 中移除serviceType 的所有实现

3. 注册接口的多个实现

我们知道,在service collection中,是可以存在一个接口多个实现的注册信息的,那么我们有什么好的方法去注册一个接口的多个实现么? TryAddEnumerable

services.TryAddEnumerable(new[]
            {
                ServiceDescriptor.Singleton<ICourtBookingRule, ClubIsOpenRule>(),
                ServiceDescriptor.Singleton<ICourtBookingRule, MaxBookingLengthRule>(),
                ServiceDescriptor.Singleton<ICourtBookingRule, MaxPeakTimeBookingLengthRule>(),
            });

=== 等价于
           services.TryAddEnumerable(ServiceDescriptor.Singleton<ICourtBookingRule, ClubIsOpenRule>());
            services.TryAddEnumerable(ServiceDescriptor.Singleton<ICourtBookingRule, MaxBookingLengthRule>());
            

 

4. 工厂模式

工厂模式允许我们在创建service 时候更加随心所欲, 拥有自己的掌控度。

services.TryAddSingleton<EmailNotificationService>();
services.TryAddSingleton<SmsNotificationService>();

 services.AddSingleton<INotificationService>(sp =>
        new CompositeNotificationService(
            new INotificationService[]
             {
                    sp.GetRequiredService<EmailNotificationService>(),
                    sp.GetRequiredService<SmsNotificationService>()
              })); 

例子中的使用场景是: 我们通过 CompositeNotificationService 去组合各种的 INotificationService, 因此使方不需要关心如何发notification 或者需要发送多少类型的notification。

------------------------

鉴于后续内容还有不少,关于在DI 使用时的注意事项,及引入第三方的依赖注入框架,剩下内容会更新在下一篇。欢迎大家讨论交流,指出不足,谢谢!

    原文作者:懒懒的佩奇
    原文地址: https://www.cnblogs.com/peppa-nan/p/14978185.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。