写这篇文章的心情:激动
Microsoft.Extensions.DependencyInjection在github上同样是开源的,它在dotnetcore里被广泛的使用,比起之前的autofac,unity来说,它可以说是个包裹,或者叫适配器,它自己提供了默认的DI实现,同时也支持第三方的IOC容器,在这段时间里使用了它,就想,这东西为什么被在dotnetcore里大放异彩?为什么会全程使用它?从程序的开始到程序启动起来,你可以发现它无处不在,在框架里是这样,在业务层同时也是这样。
聊聊Microsoft.Extensions.DependencyInjection知识点包括
- 它的开源地址
- IServiceCollection和IApplicationBuilder
- 自定义模块用它
- 在Startup.ConfigureServices中注册自定义模块
- 在Startup.Configure中使用它,进行默认模块的初始化
- 在任意对象的构造方法中使用它
一步一步的揭秘
一 它的开源地址
https://github.com/aspnet/DependencyInjection
可以看看它的README.md,就知道它是个大包裹,类似于大叔LindAgile里的Container,完全可以扩展支持其它第三方的IOC容器,这就像大叔经常说的那句话一样,在IT江湖中,英雄总是所风略同……
二 dotnetcore整个框架在用它
在你的dotnetcore应用程序里,你会发现在Startup类中有很多像services.AddMvc()这样的方法,这实质是像应用程序中注册一个组件,这里的MVC是一个统一的组件,它不依赖于windows,不依赖于dotnet,整个dotnetcore里把很多组件都解耦了,这样在维护和nuget包升级时都更灵活,自己有问题就优化自己,而不影响其它模块。(越说越像微服务的宗旨)。
IServiceCollection主要用来注册服务,就是某个接口和某种实现的对应关系,这种注册是我们在Startup.ConfigureServices方法里完成的,如下面的AddLind()这个方法,它完成了对Lind模块的注册,在方法内部可以注册本模块的其它服务。
/// <summary> /// 添加Lind框架和它们依赖子模块 /// </summary> /// <param name="services"></param> /// <param name="setupAction"></param> /// <returns></returns> public static LindBuilder AddLind( this IServiceCollection services, Action<LindOptions>