Castle下IOC的原理与实现.docVIP

Castle下IOC的原理与实现 　　摘要:在软件开发中,我们经常需要面对如何将程序元素组装成类聚的应用程序,如何有效地管理组件和组件间的相互调用装载,成为应用程序开发的重要任务,IOC(Inversion of Control,控制反转) 框架的发展,满足了这个方面的需求。文中讨论了IOC 模式的基本概论、控制反转(IOC)的基本原理、Castle IOC 容器配置构建,重点介绍了IOC的分析与实现。 　　关键词:控制反转;依赖注入;框架 　　中图分类号:TP311文献标识码:A文章编号:1009-3044(2009)13-3428-02 　　 　　1 引言 　　在软件应用开发中,“ 轻量级容器”越来越受到广泛关注,其中基于.NET应用的Castle框架下的IOC容器就是其中一个优秀的轻量级容器。轻量级容器能够帮助开发者将来自不同项目的组件组装成为一个内聚的应用程序。它们有着同一个模式,这个模式决定了这些容器进行组件装配的方式。通常这个模式被称之为“控制反转”( IoC) 或者“依赖注入”。轻量级容器可以定义更为细粒度的组件,甚至这个组件只有一个对象。以依赖注入为代表的解耦模式,可以让组件不去依赖容器的API。轻量级容器通过反转控制让容器具有主动权,去管理插进来的组件。只要组件是符合标准的,就可以被轻量级容器管理。IOC/DI 要解决的就是程序之间调用的一个问题,它应该是一个思想层面的东西.。基于IOC/DI原理,可衍生出不同种类的模式与框架。这些模式与框架可提供一种新的机制管理业务对象及其依赖关系,可以减少“粘合”代码,使依赖外置化,可以在统一的地方管理依赖,从而有效地降低软件开发问题的复杂度、减小维护的代价。 　　 　　2 Castle IOC的基本概论 　　Castle框架(framework)是一个相互协作的组织角色,构建一个针对特定环境的可复用设计基础。通常情况下,框架的核心由两个部分构成:(1)Template Method模式,划定框架执行业务操作的流程。(2)组件容器,将合适的组件填入Template Method。框架的工作是首先创建符合特定规范(包括接口和元数据)约束的组件,然后通过某种方式注册组件,等待容器将组件创建出来,最后框架在Template Method中调用用户实现的业务逻辑(或者持久化对象)。 　　IOC容器(container)是组件创建、生存的环境。容器约定了组件必须遵循加载的规范,负责以使用者需求的方式创建、装配组件,管理组件的生命周期,并将组件提供使用者,在这里容器充当了一个管理者(或者是调度者)的角色。在通常的IOC应用中,组件的装配很可能是一个递归的过程,比如组件的使用者是另外一个等待装配的组件。通过这个递归,容器可以实现结构复杂的多个组件的装配。 　　 　　3 控制反转(IOC)的基本原理 　　在面向对象设计方法中经常要涉及到一个对象对另一个对象的引用,这种依赖关系可能是因为业务逻辑的需要,也可能是因为数据持久化的需要,这种依赖关系一般是正向进行的,我们使用抽象接口来隔者和具体实现之间的依赖关系,但是不管再怎么抽象,最终还是要创建具体实现类的实例,这种创建具体实现类的实例对象就会造成对于具体实现的依赖,为了消除这种创建依赖性,需要把依赖移出到程序的外部(比如配置文件)。使用DI(依赖注入)后,这些类完全是基于抽象接口编写而成的,所以可以最大限度地适应需求的变化。 　　IOC,就是由容器控制程序之间的关系,而非传统实现中由程序代码直接操控。控制权由应用代码中转到了外部容器,控制权的转移,称为反转。相对IOC 而言,“依赖注入”更加准确地描述了这种设计理念。所谓依赖注入,即组件之间的依赖关系由容器在运行期决定,形象地来说,即由容器动态地将某种依赖关系注入到组件之中。依赖注入机制,可以在运行期为组件配置所需资源,而无需在编写组件代码时就加以指定,从而在相当程度上降低了组件之间的耦合。依赖注入的目标并非为软件系统带来更多的功能,而是为了提升组件重用的概率,并为系统搭建一个灵活、可扩展的平台。 　　IOC 的类型主要有以下几种: 　　1) 基于方法(Method) 的IOC。 　　在每个方法调用中传递其依赖的组件。如果方法需要某个组件,就把该组件作为参数传递给方法。 　　2) 基于接口的IOC。 　　使用接口来声明依赖。EJB 容器就是一个基于接口的重量级容器,部署在它内部的EJB 组件需要使用接口来声明依赖关系。 　　3) 基于Setter 方法的IOC。 　　使用setters 来设置依赖组件,使用getters 来取得组件。把依赖的组件作为一个属性,通过setters 方法来动态设置其依赖的组件。 　　4) 基于构造函数的IOC。