网站规划与开发技术专业,网站域名续费一年多少钱,凡科建站官网地址,企业网站新模式关于 Microsoft Extension: DependencyInjection 的介绍已经很多#xff0c;但是多数偏重于实现原理和一些特定的实现场景。作为 dotnet core 的核心基石#xff0c;这里准备全面介绍它的概念、原理和使用。这里首先介绍概念部分。1. 概念该项目在 GitHub 的地址#xff1a;… 关于 Microsoft Extension: DependencyInjection 的介绍已经很多但是多数偏重于实现原理和一些特定的实现场景。作为 dotnet core 的核心基石这里准备全面介绍它的概念、原理和使用。这里首先介绍概念部分。1. 概念该项目在 GitHub 的地址https://github.com/aspnet/Extensions/tree/master/src/DependencyInjectionMicrosoft.Extensions.DependencyInjection 是微软对依赖倒置原则的实现。作为 ASP.NET Core 的基石DependencyInjection 贯穿了整个项目的方方面面掌握它的使用方式和原理不仅对理解 ASP.NET Core 有重要意义也有助于将它运用到其它项目的开发中帮助提供项目开发的效率和质量。1.1 问题的场景在软件开发中项目通常有多个不同的模块组成模块之间存在依赖关系。例如我们考虑一个简化的场景我们有 3 个关于用户的类AccountController提供用户交互界面UserService提供用户管理的业务逻辑UserRepository提供用户管理的数据访问AccountController 内部需要使用 UserService 的实例 来管理用户而 UserService 内部则需要基于 UserRepository 来提供数据访问。我们称它们之间存在依赖关系。或者表达为AccountController 依赖于 UserService 而 UserService 依赖于 UserRepository 。而依赖注入就是用来帮助我们实现依赖管理的有力工具。1.2 依赖倒置原则 DIP依赖倒置原则是广为人知的设计原则之一该原则是实现软件项目中模块的解耦的理论基石。原则的定义如下High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstracts.翻译过来为高层模块不应该依赖低层模块两者都应该依赖抽象抽象不应该依赖细节细节应该依赖抽象在没有实现依赖倒置原则的时候我们通过在 AccountController 类中自己通过 new 关键字来创建其依赖的 UserService 对象实例public class AccountController {private readonly UserService _userService;public AccountController() {this._userService new UserService(); }}这导致了两个类之间的紧耦合AccountController 与 UserService 被绑定到一起 在每次创建 AccountController 的时候一定会创建一个 UserService 的对象实例而如果我们需要测试 AccountController 的时候也就不得不考虑 UserService这样一级一级的依赖下来UserService 又会依赖 UserRepository就会发现项目中的类都被绑定在一起 紧密耦合难以分拆。基于依赖倒置的原则通常会考虑通过接口进行隔离。例如我们可能会定义一个用户服务的接口public interface IUserService{}而用户服务则会实现该接口public class UserService : IUserService {}在 AccountController 类中则改变成了基于接口来使用 UserService。public class AccountController {private readonly IUserService _userService;public AccountController() {this._userService new UserService(); }}虽然在 HomeController 内部我们可以基于接口编程了但是这样的作法并没有解决自己通过 new 来获取 UserService 对象实例的问题。1.3 控制反转 IoCIoC是一种著名的实现 DIP 的设计模式。它的核心思想是在需要对象实例的时候不要总考虑自己通过 new 来创建对象放下依赖对象的创建过程而是把创建对象的工作交给别人来负责这个别人我们通常称为 容器 (Container) 或者 服务提供者 (ServiceProvider) 我们后面使用这个 ServiceProvider 来指代它在需要对象实例的时候从这个 ServiceProvider 中获取。下面是一个广泛使用的示意图。拿总是要拿的但是从 自己穿上 变成了 给你穿上在控制反转中引入了一个 ServiceProvider 来帮助我们获得对象实例。1.4 依赖注入 DI (DependencyInjection)DI 是 IoC 模式的一种实现。《Expert one on one J2EE Development without EJB》第 6 章IoC 的主要实现方式有两种依赖查找依赖注入 (p128)依赖注入是一种更可取的方式。(p130)Martin Fowler 的原文As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.大意是已经存在某种模式该模式被称为 IoC但 IoC 太过广义任何框架都 IoC为了让表意更明确决定采用 DI 来精确指称它。DI 的实现有多种我们这里介绍的是微软官方在 Microsoft Extension 中内置提供的 DependencyInjection。它是 IoC 中一种实现ASP.NET Core 的整个核心基于它来实现。同时我们也可以在其它项目中使用以实现对依赖倒置原则的支持。2. DependencyInjection 中的基本概念2.1 服务描述集合 ServiceCollection在微软的 DI 实现中所有的服务需要首先注册到一个公共的服务描述集合中该集合对于整个 DI 来说只需要一个服务只需要在此集合中注册一次即可在以后通过 DI 提供给使用者。该集合的接口定义为 IServiceCollection可以看出来它其实就是一个用来保存服务注册的集合。public interface IServiceCollection : IListServiceDescriptor, ICollectionServiceDescriptor, IEnumerableServiceDescriptor, IEnumerable{}系统默认已经实现了一个对 IServiceCollection 的实现名为 ServiceCollection。在 ASP.NET Core 中内部会创建该对象的实例我们也可以在其它项目中自己来创建它很简单直接 new 出来就可以使用了。IServiceCollection services new ServiceCollection ();2.2 服务 Service在 DI 语境中服务特指通过 DI 容器管理的对象实例。这个服务并不一定被称为 **Service而是可以是任何由 DI 所管理的对象只是在 DI 这个语境下我们将其统称为服务。服务是我们自己定义的例如前面提到的 AccountController 和 UserService 等等。我们通过 DI 来获得服务对象实例管理服务对象的生命周期对于存在复杂依赖关系的对象 DI 还负责管理这些实例之间的依赖关系。服务必须首先注册在 DI 中才能使用但是注册前需要首先考虑和决定服务的生命周期。2.3 服务的生命周期服务对象实例有着不同类型的生命周期。有些对象的生命周期与应用程序相同在应用程序启动时创建在应用程序退出时才需要释放。例如我们的数据访问对象实例。有些对象仅仅在当前方法中使用在方法调用结束之后就应该销毁。服务的生命周期管理用来管理这些需求。DI 支持三种类型的生命周期Singleton单例在当前应用程序环境下只有一个实例。例如数据访问服务对象实例。Scoped限定范围一旦退出此范围在此范围内的服务对象都需要销毁。例如 Web 开发中的请求对象实例。Transient瞬态一次性使用每次从 DI 中获取都返回一个新的实例。Microsoft.Extensions.DependencyInjection.ServiceLifetimepublic enum ServiceLifetime{ Singleton, Scoped, Transient}服务的生命周期在注册服务的时候确定。在使用的时候直接获取实例不再指定服务的生命周期。微软提供了多种扩展方法来便于在注册服务时指定服务的生命周期。例如下面是通过泛型方式来指定单例模式的生命周期。// 基于接口的注册services.AddSingletonIUserService, UserService();2.4 服务提供者 ServiceProvider在需要使用服务对象实例的时候不是从注册服务的集合中获取而是需要通过服务提供者来获取这个服务提供者显然需要来自注册服务的集合。服务提供者的接口定义为 IServiceProvider它是 .net 的基础定义之一不是在该 DI 框架中定义的。public interface IServiceProvider{object GetService(Type serviceType);}DI 中的 ServiceCollectionContainerBuilderExtensions 扩展了 IServiceCollection提供了获得这个服务提供者 ServiceProvider 的支持。public static ServiceProvider BuildServiceProvider(this IServiceCollection services){return BuildServiceProvider(services, ServiceProviderOptions.Default);}所以我们通常使用该方法来获取并使用它。// 创建注册服务的容器IServiceCollection services new ServiceCollection ();// 注册服务这里指定了单例services.AddSingletonIUserService, UserService();// 通过容器获得服务提供者IServiceProvider provider services.BuildServiceProvider ();2.5 获取服务对象实例通过服务提供者来手动获取服务对象实例。通过注册的服务类型直接调用 GetService 方法即可。例如前面我们注册了服务类型 IUserService 的实现类型是 UserService 那么可以通过此类型来获取实际实现该接口的对象实例。// 创建注册服务的容器IServiceCollection services new ServiceCollection ();// 注册服务这里指定了单例services.AddSingletonIUserService, UserService();// 通过容器获得服务提供者IServiceProvider provider services.BuildServiceProvider ();// 通过接口获取服务对象实例IUserService instance provider.GetServiceIUserService ();看起来更加复杂了。在实际使用中我们很少使用这样的方式来使用 DI后面我们再深入讨论具体的使用过程。原文链接https://www.cnblogs.com/haogj/p/11370314.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
