拥抱.NET Core系列:依赖注入(1)

依赖注入时编程手段中解耦和封装的一个非常重要的手段,我本人已经到了没有DI无法编写项目的程度了,在.NET Framework中微软并没有在FCL中引入DI,虽然推出了“Unity”。而在.NET Core中DI几乎是所有组件的标配可见DI有多么的重要,本节主要简单介绍下微软在.NET Core中加入的DI组件。

前言

DIP、IoC、DI

说起DI不得不提IoC这个模式,很多人会把DI和IoC混为一谈,但其实这两者是概念和实现的关系。

依赖倒置原则(DIP):软件设计原则,要依赖于抽象,不要依赖具体实现。

控制反转(IoC):一种实现DIP原则的模式。

依赖注入(DI):IoC的具体实现。

DIP就好比一个目标一个法则。

IoC就好比是论文,“应该怎么做才能遵循DIP”

DI就好比是实际的产品,“落实到具体的语言的工具”

关于这个比喻可能不是很准确,大家可以使用搜索引擎去了解更为详细的差异。

在.NET

在我接触的很多.NET项目中,很少有人使用DI,更别提像Orchard那样把DI用得出神入化。而复杂的代码很大一部分的原因是没有引入DI。在java中几乎从刚入门的新手都使用Spring提供的DI。

依赖注入生命周期

生命周期是指对服务实例的存活状态控制,"Microsoft.Extensions.DependencyInjection"提供了一个枚举定义了三种生命周期状态。

类型 描述
Singleton 单例服务,从当前服务容器中获取这个类型的实例永远是同一个实例。
Scoped 域内单例,为每个作用域创建一个服务实例,也就是说域内单例(域类似子容器)。
Transient 瞬态,从服务容器中每获取一次创建一个新的实例。

用例服务

代码如下:

注册服务的N种姿势

其实可以很容易的看出,服务注册是通过创建一个“ServiceDescriptor”来完成的,而其它方式的注册只不过是基于一个方法的封装而已,让使用者可以更为方便的进行服务注册。

我们可以通过很多手段去注册一个服务,但这里推荐大家优先使用扩展方法进行服务注册,因为这样的代码更易读。反射循环注入时可以使用其它方式。

服务使用

首先我们来看一下服务提供者提供的方法签名。

可以发现与服务注册一样,基于同一个方法提供了很多扩展方法让使用者更加便捷的获取服务。

我们先来看“GetService<T>”与“GetRequiredService<T>”这两个方法。

这两个方法非常接近,唯一不同的是GetRequiredService会在找不到服务的时候抛出异常,而GetService在找不到服务时会返回null。

“GetServices”这个方法是用来获取多个服务实例,该方法会返回该类型注册的多个服务实例。我们来看个例子:

服务的生命周期

我们可以通过运行结果很好的理清各个生命周期的用意。下面用一张图来说明较复杂情况下“scope”的服务结果。

小技巧

注册支持延迟加载的服务

开发过程中经常有一种情况,服务A的A方法依赖了服务B,而服务A的B方法依赖了服务C,这时候你就得在构造函数上同时声明服务B和C,就像这样。

这在其它DI组件中非常常见,比如autofac。而在现在我们需要这样做:

写在最后

.NET技术栈QQ群:384413261(点击加入.NET Group

时间: 2024-08-04 17:39:37

拥抱.NET Core系列:依赖注入(1)的相关文章

拥抱.NET Core系列:MemoryCache 缓存域

在上一篇“<拥抱.NET Core系列:MemoryCache 缓存选项>”我们介绍了一些 MSCache 的机制,今天我们来介绍一下 MSCache 中的缓存域. MSCache项目 MSCache 目前最新的正式版是 2.0.0,预览版是2.1.0,会与 .NETCore 2.1 一起发布.本篇用了2.0.0版本 开源在 GitHub 上,仓库地址是:https://github.com/aspnet/Caching NuGet地址为:https://www.nuget.org/packa

net core WebApi——依赖注入Autofac

目录 前言 Autofac 添加一个Util来随时调用 小结 代码地址 预告 前言 周末加班,下午犯困,整理下之前鼓捣过的东西,看过我之前的webapi系列的读者知道,我之前试过Aspect,但是升级到3.0之后没往下去试了,当时还留了个坑,这不,现在果断移除了换成这个了. Autofac 这个第三方类库呢,是Ioc的容器,可以简化我们很大的工作量,比如说在之前我们需要写个类去声明接口与实现,而用了这个容器呢,就不需要了,当然还是需要些配置的. 首先,引入第三方类库,不多说. 然后开始配置吧,首

.Net Core 使用依赖注入

ASP.NET Core 源码阅读笔记(1) ---Microsoft.Extensions.DependencyInjection 在asp .net中使用依赖注入很简单,只需要在Startup类的ConfigureServices(IServiceCollection services)方法中,通过IServiceCollection接口注入就行. 通过接口的Add*方法进行注册,代码如下: ASP.NET Core runtime帮忙注册如下方法 // This method gets c

用工厂模式解决ASP.NET Core中依赖注入的一个烦恼

这是最近在实际开发中遇到的一个问题,用 asp.net core 开发一个后端 web api ,根据指定的 key 清除 2 台 memcached 服务器上的缓存.背景是我们在进行 .net core 迁移工作,asp.net 项目与 asp.net core 项目并存,为了避免两种类型项目的缓存冲突,我们分别用了 2 台不同的 memcached 服务器. 之前使用 1 台 memcached 服务器时,只需要一个客户端,所以只需创建一个 MemcachedClient 单例并注入到 IM

【ASP.NET Core】依赖注入高级玩法——如何注入多个服务实现类

依赖注入在 ASP.NET Core 中起中很重要的作用,也是一种高大上的编程思想,它的总体原则就是:俺要啥,你就给俺送啥过来.服务类型的实例转由容器自动管理,无需我们在代码中显式处理. 因此,有了依赖注入后,你的编程思维就得变一变了.在过去,许多功能性的类型(比如一个加密解密的类),我们都喜欢将其定义为静态(static),而有了依赖注入,你就要避免使用静态类型,应该交由服务容器帮你管理,只要你用好了,你会发现依赖注入是很方便的. 依赖注入的初级玩法,也是比较标准的玩法,此种玩法有两种模式:

Catel帮助手册-Catel.Core:(5)依赖注入(ServiceLocator and TypeFactory)

1,简介 在Catel2.0之前,IOC容器内部使用的是Unity,然而,这就强制所有的用户在他的应用程序中使用Unity作为IOC容器,也需要这样划分库,从2.0以后,一个不同的技术被使用了,这个允许开发者可以使用他们自己悬着的IOC容器技术. 1.1在Ioc中不同的组件 在Catel中有许多不同的组件他们对于Ioc是非常重要的. ServiceLocator 该组件用于注册所有的类型,这个事真正的Ioc容器 TypeFactory 用于创建类型的组件,使用IServiceLocator来获取

.NET Core 中依赖注入 AutoMapper 小记

最近在 review 代码时发现同事没有像其他项目那样使用 AutoMapper.Mapper.Initialize() 静态方法配置映射,而是使用了依赖注入 IMapper 接口的方式 services.AddSingleton<IMapper>(new Mapper(new MapperConfiguration(cfg => { cfg.CreateMap<User, MentionUserDto>(); }))); 于是趁机学习了解一下,在 github 上发现了 A

拥抱.NET Core系列:Logging (1)

在之前我们简单介绍了 .NET Core 中的 DI组件,没来及了解的童鞋可以翻翻我之前的文章. 接下来会对 .NET Core 中的 Logging 进行介绍. 本文中使用了"Microsoft.Extensions.Logging.Console"做为输出目标,后续文章会详解. Logging 中的三剑客 可以看到 Logging 的核心抽象就是三个接口,分别是: ILogger:负责具体的日志写入逻辑,如:FileLogger,ConsoleLogger,SQLLogger,El

Asp.Net.Core 系列-中间件和依赖注入进阶篇

上一节讲了中间件和依赖注入的基础,紧接着: 中间件是怎么使用的?使用步骤是什么? 只要把中间件注册到管道中就行了,可以借助Startup对象(DelegateStartup或者ConventionBasedStartup)来完成之外,也可以利用另一个叫做StartupFilter的对象来实现.所谓的StartupFilter是对所有实现了IStartupFilter接口的类型及其对象的统称.IStartupFilter接口定义了如下一个唯一的方法Configure,该方法的参数next返回的Ac