依赖注入与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_实现传递给它.

  •   class ServiceUser
         {
             IServiceProvider sp;
             ServiceUser(IServiceProver sp)
             {
                 this.sp = sp;
             }
         }
    
         private MutablePicoContainer configureContainer() {
             MutablePicoContainer pico = new DefaultPicoContainer();
             //下面就是把ServiceProvider和ServiceUser都放入容器的过程，以后就由容器来提供ServiceUser的已完成依赖注入实例，
             //其中用到的实例参数和类型参数一般是从配置档中读取的，这里是个简单的写法。
             Parameter[] finderParams =  {new ConstantParameter("movies1.txt")};
             pico.registerComponentImplementation(IServiceProvider.class, ServiceProvider.class, finderParams);
             pico.registerComponentImplementation(ServiceUser.class);
             //至此，容器里面装入了两个类型，其中没给出构造参数的那一个（ServiceUser）将依靠其在构造器中定义的传入参数类型，在容器中
             //进行查找，找到一个类型匹配项即可进行构造初始化。
             return pico;
         }

    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的目的
• 用来降低主程序与对象间的关联.
• 同时也能减低对象间的关联.
• 简化对象的建立动作,进而让对象更加容易使用.