DIP原则、IoC以及DI
一、DIP原则
高层模块不应该依赖于底层模块,二者都应该依赖于抽象。
抽象不应该依赖于细节,细节应该依赖于抽象。
该原则理解起来稍微有点抽象,我们可以将该原则通俗的理解为:"依赖于抽象”。
该规则告诉我们,程序中所有的依赖关系都应该终止于抽象类或者接口
,从而达到松耦合的目的。因为我们在应用程序中编写的大多数具体类都是不稳定的
。我们不想直接依赖于这些不稳定的具体类。通过把它们隐藏在抽象和接口
的后面,可以隔离它们的不稳定性。
举个例子
一个Button对象会触发Click方法,当被按下时,会调用Light对象的TurnOn方法,否则会调用Light对象的TurnOff方法。
这个设计存在两个问题:
Button类直接依赖于Light类,这种依赖关系意味着当Light改变时,Button类会受到影响;
Button对象只能控制Light对象,想要控制电视或者冰箱就不行了;
新的设计:
这个方案对那些需要被Button控制的对象提出了一个约束。需要被Button控制的对象必须要实现ISwitchableDevice接口。
所为原则
,只是描述了什么是对的,但是并没有说清楚如何去做。在软件工程中,我们经常使用DI(依赖注入)
来达到这个目的。但是提到依赖注入,人们又会经常提起IoC
这个术语。所以先让我们来了解下什么是IoC。
二、IoC
IoC的全名是Inverse of Control,即控制反转。这一术语并不是用来描述面向对象的某种原则或者模式,IoC体现为一种流程控制的反转,一般用来对框架进行设计。
举个例子
ReportService是一个用来显示报表的流程,该流程包括Trim()
,Clean()
,Show()
三个环节。
public class ReportService{ private string _data;
public ReportService(string data) {_data = data;} public void Trim(string data) {_data = data.Trim();} public void Clean() {_data = _data.Replace("@", "");_data = _data.Replace("-", ""); //...other rules} public void Show() {Console.WriteLine(_data);}}
客户端通过下面的方式使用该服务:
var reportService = new ReportService(input);
reportService.Trim(input);
reportService.Clean();
reportService.Show();
这样的一个设计体现了过程式的思考方式,客户端依次调用每个环节从而组成了整个报表显示流程,这样的代码体现了:客户端拥有流程控制权。
我们来分析下这段代码,ReportService提供了3个可重用的Api,正如ReportService的命名一样,它告诉我们它是一个服务,我们只能重用他提供的三个服务,它无法提供一个打印报表的流程,整个流程是客户端来控制的。
另外,该设计也违反了tell, Don't ask原则。
打印报表作为一个可复用的流程,不但可以提供可复用的流程环节,还可以提供可复用的流程的定义,当我们进行框架设计的时候,往往会将整个流程控制定制在框架之中,然后提供扩展点供客户端定制。这样的思想体现了流程的所有权从客户端到框架的反转。
比如asp.net mvc或者asp.net api框架,内部定义了http消息从请求,model binder,controller的激活,action的执行,返回response
等可复用的流程。同时还提供了每一个环节的可扩展点。
利用以上思想,我们对ReportService重新设计。
新的设计
采用IoC思想重新设计该报表服务,将原来客户端拥有的流程控制权反转在报表服务框架中。ReportService
这样的命名已经不适合我们的想法,新的实现不但提供了报表打印的相关服务,同时还提供了一个可复用的流程,因此重新命名为ReportEngine
。我们可以通过模板方法达到此目的:
public class ReportEngine{ private string _data; public ReportEngine(string data) {_data = data;} public void Show() {Trim();Clean();Display();} public virtual void Trim() {_data = _data.Trim();} public virtual void Clean() {_data = _data.Replace("@", "");_data = _data.Replace("-", "");} public virtual void Display() {Console.WriteLine(_data);}}
此时的报表服务在Show()
方法中定义好了一组可复用的流程,客户端只需要根据自己的需求重写每个环节即可。客户端可以通过下面的方式使用ReportEngine
var reportEngine=new StringReportEngine(input);
reportEngine.Show();
三、DI(Dependency Injection)
DI即依赖注入,主要解决了2个问题:
松耦合,由DI容器来创建对象,符合DIP原则;
符合IoC的思想,整个应用程序事先定义好了一套可工作的流程,通过在客户端替换DI容器中的具体实现达到重写某个组件的目的;
除此之外,使用依赖注入还可以带来以下好处:
促使你写出更加符合面向对象原则的代码,符合优先使用对象组合,而不是继承的原则;
使系统更加具有可测试性;
使系统更加具备可扩展性和可维护性;
由于所有组件都由DI容器管理,所以可以很方便的实现AOP拦截
我记得之前在stackoverflow上看到过类似这样的一个问题:
如何给5岁小孩解释什么叫DI?
得分最高的答案是:小孩在饿的时候只需喊一声我要吃饭即可,而无需关注吃什么,饭是怎么来的等问题。
public class Kid{ private readonly IFoodSupplier _foodSupplier; public Kid(IFoodSupplier foodSupplier) {_foodSupplier = foodSupplier;} public void HaveAMeal() { var food = _foodSupplier.GetFood(); //eat}
}
DI的背后是一个DI Container(DI容器)在发挥作用。DI之所以能够工作需要两个步骤:
将组件注册到DI容器中;
DI容器统一管理所有依赖关系,将依赖组件注入到所需要相应的组件中;
3.1 组件的注册方式
组件注册到DI容器中有3种方式:
通过XML文件注册
通过Attribute(Annotation)注册
通过DI容器提供的API注册
.net平台中的大多数DI框架都通过第三种方式进行组件注册,为了介绍这3种不同的注册方式,我们通过Java平台下的Spring框架简单介绍:Java中的Spring最早以XML文件的方式进行组件注册,发展到目前主要通过Annotation来注册。
假如我们有CustomerRepository
接口和相应的实现CustomerRepositoryImpl
,下面用三种不同的方式将CustomerRepository
和CustomerRepositoryImpl
的对应关系注册在DI容器中:
public interface CustomerRepository { List<Customer> findAll();
}
public class CustomerRepositoryImpl implements CustomerRepository { public List<Customer> findAll() { List<Customer> customers = new ArrayList<Customer>();Customer customer = new Customer("Bryan","Hansen");customers.add(customer); return customers;}
}
3.1.1、xml文件注册
<bean name="customerRepository" class="com.thoughtworks.xml.repository.CustomerRepositoryImpl"/>
3.1.2、Annotation注册
@Repository("customerRepository")
public class CustomerRepositoryImpl implements CustomerRepository { public List<Customer> findAll() { //...}
}
3.1.3、通过Java代码来实现注册
@Configurationpublic class AppConfig { @Bean(name = "customerRepository") public CustomerRepository getCustomerRepository() { return new CustomerRepositoryImpl();}
}
3.1.4通过下面的方式从Container来获取一个实例
appContext.getBean("customerService", CustomerService.class);
一旦我们将所有组件都注册在容器中,就可以靠DI容器进行依赖注入了。
3.2 依赖注入的三种方式
3.2.1. 构造器注入
正如上面Kid
的实现一样,我们通过构造器来注入IFoodSupplier
组件,这种方式也是依赖注入最佳方式。
3.2.2. 属性注入
public class Kid2{
public IFoodSupplier FoodSupplier { get; set; }
public void HaveAMeal() {
var food = FoodSupplier.GetFood(); //eat}
}
即通过一个可读写的属性完成注入,该方案的缺点在于为了达到依赖注入的目的而破坏了对象的封装性,所以不推荐。
3.2.3 方法注入
通过添加方法的参数来完成注入,一般来说这种方式都可以通过构造器注入的方式来替换,所以也不太常用。值得一提的是asp.net core源码中用到了这种注入方式。
四、依赖注入实例
1、Register Resolve Release Pattern
下面描述了一个很简单的Console application, 所有的组件都通过Castle Windsor容器进行构造器注入:
//registervar container = new WindsorContainer();
container.Register(Component.For<IParser>().ImplementedBy<Parser>());
container.Register(Component.For<IWriter>().ImplementedBy<Writer>());
container.Register(Component.For<Application>());//resolvevar application = container.Resolve<Application>();
application.Execute("hel--lo, wor--ld");//releasecontainer.Release(application);
这个例子向我们展示了一个最简单的依赖注入使用方式,register所有组件,resolve客户端程序,最后的release步骤向我们展示了如果显示从DI容器得到一个对象,应该显示释放该组件。这一步在大多数情况下并不是必须的,但是在特定场景下会发生内存泄漏。
2、.net平台下依赖注入最佳实践
下面的解决方案描述了一个典型的应用程序分层结构,该分层结构用来描述如何使用Catle windsor
进行依赖注入,注意:这并不是一个合理的领域驱动案例,例如我将Domain
模型引用到了Application
或者ApplicationService
程序集中。
处在项目最底层的Repository
程序集定义了一组UserRepository
及其接口IUserRepository
,这样的一个组件如何注册在Windsor Container中呢?Castle提供了一种叫做WindsorInstaller
的机制:
public class RepositoryInstaller:IWindsorInstaller{ public void Install(IWindsorContainer container, IConfigurationStore store) {container.Register(Component.For<IUserRepository>().ImplementedBy<UserRepository>().LifestyleScoped());}
}
该Installer利用Fluent Api定义了IUserRepository
和UserRepository
的对应关系,相对于Java中的Spring框架提供的代码注册方式,该方案的优越之处是显而易见的。
另外的重点在于该Installer此时并没有执行,只有当客户端调用此Installer时,该组件才真真注册进容器。这一点很关键,我们后面还会提到。
接下来的ApplicationService
层使用了Repository
的抽象,一个典型的使用片断如下:
public class UserApplicationService : IUserApplicationService{
private readonly IUserRepository _userRepository;
public UserApplicationService(IUserRepository userRepository) {_userRepository = userRepository;}
public void Register(User user) {_userRepository.Save(user);} //.....}
我们通过构造器注入的方式注入了IUserRepository
,同时,作为Service层,它也拥有自己的Installer:
public class ApplicationServiceInstaller:IWindsorInstaller{
public void Install(IWindsorContainer container, IConfigurationStore store) {container.Register(Classes.FromThisAssembly().BasedOn<IApplicationService>().WithServiceDefaultInterfaces().LifestyleScoped());}
}
上面的例子示范了如何通过Castle提供的高级api来实现将该程序集中所有继承于IApplicationService
的组件和其默认接口一次性全部注册到DI容器中。
比如UserApplicationService
和IUserApplicationService
,以及未来将要实现的OrderApplicationService
以及IOrderApplicationService
。
接下来到客户端程序集Application层,Application作为使用ApplicationService
程序集的客户端,他才拥有将组件注册进DI容器的能力,我们定义一个ApplicationBootstrap
来初始化DI容器并注册组件:
public class ApplicationBootstrap{
public static IWindsorContainer Container { get; private set; }
public static IWindsorContainer RegisterComponents() {Container=new WindsorContainer();Container.Install(FromAssembly.This());Container.Install(FromAssembly.Containing<ApplicationServiceInstaller>());Container.Install(FromAssembly.Containing<RepositoryInstaller>()); return Container;}
}
注意Container.Install(...)
方法将执行不同应用程序的Installer,此时组件才真真注册进DI容器。该实例展示了如何正确的使用依赖注入框架:
不同的程序集之间通过接口依赖,符合DIP原则;
通过依赖注入的方式定义好了可运行的流程,但是客户端可以注册不同的组件到DI容器中,符合IoC的思想;
3、如何在asp.net mvc和asp.net webapi使用依赖注入
本文提供的源码中所含的WebApplicationSample
项目演示了如何通过自定义WindsorControllerFactory
来实现mvc的依赖注入,通过自定义WindsorCompositionRoot
实现web api的依赖注入。
五、高级进阶
asp.net core实现了一个还算简单的DI容器DenpendencyInjection,感兴趣的同学可以阅读其源码。
原文地址:http://www.cnblogs.com/richieyang/p/6060160.html
.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注
DIP原则、IoC以及DI相关推荐
- 深入理解DIP、IoC、DI以及IoC容器
对于大部分小菜来说,当听到大牛们高谈DIP.IoC.DI以及IoC容器等名词时,有没有瞬间石化的感觉?其实,这些"高大上"的名词,理解起来也并不是那么的难,关键在于入门.只要我们入 ...
- DIP、IoC、DI笔记整理
DIP.IoC.DI笔记 什么是DIP 摘录自[01] DIP:依赖倒置原则(Dependence Inversion Principle) 高层模块不应该依赖于低层模块.二者都应该依赖于抽象. 抽象 ...
- 设计模式--谈谈IoC、DI、DIP、IoC Container、控制反转与依赖注入
1. 介绍 控制反转(IoC).依赖反转原理(DIP).依赖注入(DI)和IoC容器这些术语你都清楚嘛? 2. 概念讲解 2.1. IoC 控制反转(IoC):是一种设计模式,用于在面向对象的设计中反 ...
- ASP.NET Core Web 应用程序系列(一)- 使用ASP.NET Core内置的IoC容器DI进行批量依赖注入(MVC当中应用)...
在正式进入主题之前我们来看下几个概念: 一.依赖倒置 依赖倒置是编程五大原则之一,即: 1.上层模块不应该依赖于下层模块,它们共同依赖于一个抽象. 2.抽象不能依赖于具体,具体依赖于抽象. 其中上层就 ...
- 程序员过关斩将--错误的IOC和DI
什么是IOC? 什么是DI? IOC和DI有什么关系? 作为程序员,天天撸代码,怎么能不知道IOC和DI呢.很多面试官也喜欢问这两个概念,虽然概念很简单,但是可以从面试者的回答当中,大体的可以估算到面 ...
- 自定义实现IOC与DI
自定义实现IOC思路拆解 近日在理解IOC与DI,看了很多概念,也写过很多小练习,但总觉得只是认识,不甚熟悉,蓦然回首,偶尔还能发出"大兄dei,您哪位?"的感慨.在前辈的指导下, ...
- Spring IOC与DI、反射的理解 含小案例说明
阅览了很多篇博文,对于Spring IOC和DI看到很多人介绍的感觉都很含糊,读完之后还是觉得混淆的不行,也有的人认为DI是IOC的另一种说法-emm,可能个人理解不同吧,我的观点并不然.但这种东西, ...
- Spring中的Ioc、DI到底是啥
我们都知道,Spring是一款轻量级的IOC框架,Spring的核心就是Ioc和DI,并通过俩者解耦. 那么,Ioc.DI呢? Ioc 控制反转 Ioc(Inversion of control)控制 ...
- Spring的IOC与DI的个人杂谈
Spring的IOC与DI的个人杂谈 一.前言 初学者初学Spring框架的时候,往往是伴随着SSM三大框架的学习而了解的.但是这样是不好的,我们应该在任务之余去学习一些本框架一些核心的知识点. 本篇 ...
最新文章
- 遍历JavaScript中的数组
- Android PullToRefreshListView设置各个item之间的间距
- 如何生成HDF5文件
- linux执行jar包命令没有主清单熟悉,jar命令成功完成 java -jar 命令却提示“没有主清单属性”!...
- 无人化运维离我们有多远?阿里智能化运帷平台深度揭秘
- springboot中分页插件pageHelper的使用
- 在本地安装独立的HBase和Apache Storm简单集群
- 窗体间跳转及传值 01
- netty实现消息群发
- python excel库 linux_python 在linux下读取 .xlsx
- 前端web 技术盘点
- java 重写equals的要点_浅谈java 重写equals方法的种种坑
- 导弹拦截(数据加强版)
- 苹果软解ID软件(X.PASSWORD-XIMEI 苹果id锁)--上帝左手汉化组(内附即时更新)
- Cybertec PostgreSQL透明加密解析
- Istio进入1.7版本,Service Mesh 落地还有什么障碍?
- RationalDMIS 2020 SP25扫描测头构建与校验(山涧果子)
- 解密微信小程序用户敏感数据获取用户信息
- 【前端之旅】Webpack模块打包工具
- 浅谈小微企业智能化财务转型