依赖注入与Service Locator

  • 为什么需要依赖注入?
    • ServiceUser是组件,在编写者之外的环境内被使用,且使用者不能改变其源代码.
    • ServiceProvider是服务,其类似于ServiceUser,都要被其他应用使用,不同是ServiceProvider会被用于非本地环境,需要对应不同环境.
    • 普通的ServiceUser来负责直接创建所需Service实现的实例方法.拥有以下的局限
      • 在不同的环境下,ServiceProvider是千差万别的(数据库,临时文件,内存).
      • 所以,不能将ServiceUser作为组件发布(适应不了各种差异环境).
    • 为了将ServiceUser所在单元作为组件发布,必须满足以下的条件.
      • 将ServiceUser与具体的ServiceProvider_Imp解耦(解除编译时依赖).即不能出现new ServiceProvider_Imp()语句.
      • 在运行时,根据环境来为ServiceUser来动态地提供ServiceProvider的实现实例.
      • 总之,将ServiceUser和ServiceProvider之间的依赖,由编译时,推迟到运行时动态决定.
      • 即在运行时"注入"这种依赖,称为依赖注入(DI).
      • ServiceUser可以看做框架.其需要对外发布,被其他模块使用.
      • ServiceProvider可看做插件.其在不同的环境下有差别.
    • 依赖注入
      • 在编译时,使用IServiceProvider接口.在运行时,再将具体的实现类型绑定到ServiceUser上.
      • 从而实现了服务的使用者(框架)和服务的提供者(插件)的松耦合.
    • 加入一个Assembler(容器)来完成对框架单独发布所需的要求.
      •  
  • 构造器DI
    • 构造器指的是ServiceUser的构造器,也就是在构造ServiceUser的实例时,才把具体的ServiceProvider_实现传递给它.
    •  1  class ServiceUser
 2     {
 3         IServiceProvider sp;
 4         ServiceUser(IServiceProver sp)
 5         {
 6             this.sp = sp;
 7         }
 8     }
 9 
10     private MutablePicoContainer configureContainer() {
11         MutablePicoContainer pico = new DefaultPicoContainer();
12         //下面就是把ServiceProvider和ServiceUser都放入容器的过程，以后就由容器来提供ServiceUser的已完成依赖注入实例，
13         //其中用到的实例参数和类型参数一般是从配置档中读取的，这里是个简单的写法。
14         Parameter[] finderParams =  {new ConstantParameter("movies1.txt")};
15         pico.registerComponentImplementation(IServiceProvider.class, ServiceProvider.class, finderParams);
16         pico.registerComponentImplementation(ServiceUser.class);        
17         //至此，容器里面装入了两个类型，其中没给出构造参数的那一个（ServiceUser）将依靠其在构造器中定义的传入参数类型，在容器中
18         //进行查找，找到一个类型匹配项即可进行构造初始化。
19         return pico; 
20     }
      CtorDI

       

    • 依赖被延迟到容器的构造过程中.
    • 容器本身(具体来说是其构造过程)对ServiceUser和ServiceProvider都有依赖.
    • 所以,ServiceUser,ServiceProvider,容器三者,没有任何的依赖关系.
    • 所有的依赖关系,所有的变化,都被封装到了容器的构造中.
    • 实例项目中,可以使用配置文件来将变化排斥到编译期外.
    • 容器含有一个类似GetInstance(Type t)的方法,在该方法中,容器调用ServiceUser的构造器,而使用的参数是在容器添加ServiceProvider时指定的(也就能够在不同的环境下,使用不同的ServiceProvider的实现).
  • 属性DI
    • 其与构造器DI的差别
      • 在获取对象实例时(GetInstance方法),前者通过反射得到待创建类型(ServiceUser)的构造器信息,然后根据构造器的参数类型(ServiceProvider)在容器中进行查找,然后构造出合适的实例.
      • 而属性DI是通过反射得到待创建类型的所有属性,然后根据属性的类型在容器中查找对应类型的实例.
      • 这种方式利于使用XML配置的方式来实现,所以诸如Spring的框架使用的都是这种方式.
  • 接口DI
    • 首先,在接口中定义需要注入的信息.
    • 然后,在ServiceUser中实现该接口.
    • 最后,由容器调用接口定义的注入方法来完成注入.
  • Service Locator
    • 基本思想:有一个对象(服务定位器)知道如何获取一个应用程序所需的所有服务(对象).
    • 与DI的区别
      • ServiceUser必须显示调用Service Locator的方法来获取对应的服务对象(ServiceProvider)实例.
      • 而在DI中,这个过程是由容器隐式完成的.
    • 由于ServiceUser和Servive Locator之间的依赖性,降低了模块之间的独立性,所以IOC框架大多使用的是DI.
    • 而Locator的优势是实现简单,所以当开发工作不复杂时,可以使用Service Locator.
    • 由于单个ServiceLocator会导致很多的方法接口.可以提取专用的Get接口.然后对应的ServiceUser只关心和使用其对应的接口.
  • DI和Locator的对比
    • 首先,两者的目的都是解耦ServiceUser和ServiceProvider的实现.
    • 在构筑大型应用时,会遇到一个共同的问题:如何组合系统的不同部分.
      • 例如,web控制器如何与后台的数据库层面交互.
      • 尤其是当这些不同部分是由不同的team完成,互相之间只有很少的了解.
    • 核心区别在于,ServiceProvider的实现,以什么方式提供给ServiceUser.
      • 在Locator中,ServiceUser直接发送方法调用来请求具体的ServiceProvider实现的实例.
      • 在DI中,ServiceUser不再需要任何的调用,由容器来隐式地完成将ServiceProvider的实现实例注入到ServiceUser中的过程.
    • 控制反转(IOC)是框架的基本特征.
      • 增加了框架代码的理解难度,同时增加了调试难度.
    • 在选择两者的取舍时,主要考虑的是(ServiceUser)对Locator的依赖会不会造成问题.
      • 首先,取决于ServiceUser的性质,如果有多个ServiceUser要使用同一服务,那么可以使用Locator.
      • 而如果要将ServiceUser作为组件发布供别人使用,而别人的Locator是不可预测的,很可能带来不兼容问题,所以要使用DI.
      • 另一方面, 在DI中,容器和ServiceProvider的实现没有依赖关系.除了配置文件信息,服务实现无法获取更多的关于容器的信息.
    • 使用DI模式,可以更清晰地理清组件间的依赖关系.
      • 只需要观察依赖注入机制(例如构造函数).就可以看到整个的依赖关系.
    • 而使用Locator模式,必须在源代码中搜索所有对Locator的调用才可以.
    • 测试
      • 部分人会认为DI简化了测试,因为可以非常简单地在真实和伪组件(ServiceProvider的实现)之间切换.
      • 但是,良好的Locator实现,应该能做到很容易地替换掉Locator.
      • 也就是说,良好的架构应该支持简单地使用一个伪组件来替换掉一个真实组件,来方便地进行测试.
      • 所以,如果ServiceProvider的实现如果要脱离自己的控制,在另一个环境中使用,那么就不能对Locator做任何的假定.
  • 构造DI对比属性DI
    • 基准:应该在那里填充字段(属性)的值?构造函数还是设置方法?
    • 构造函数的一个好处是隐藏不可变的字段.
      • 在构造器内将其设置,然后不提供Setter即可.
    • 构造DI的问题
      • 参数个数过多
      • 参数多是无法描述信息的简单类型.
      • 对象含有多个构造函数,且有继承关系.
  • 代码配置对比配置文件
    • 在简单的应用中,直接使用代码来完成配置.
    • 当配置文件变得越发复杂时,使用一种编程语言来编写配置文件.
  • 分离配置和使用
    • 关键:服务的配置和使用应该被分离开.
    • 实际上,这反映了一个基本的设计原则:分离接口与实现.
    • 在面向对象的程序中,我们在一个地方根据条件来决定具体实例化哪一个子类,之后使用多态(接口类型)来操作该类型.
  • DI的目的
    • 用来降低主程序与对象间的关联.
    • 同时也能减低对象间的关联.
    • 简化对象的建立动作,进而让对象更加容易使用.
posted @ 2014-06-24 14:02  robynhan  阅读(2009)  评论(0)  编辑  收藏  举报