浅谈Ioc

根据Martin Fowler的Inversion of Control Containers and the Dependency Injection pattern一文所说,控制反转,包括DI和ServiceLocator,DI又包括方法注入SI, 构造子注入CI和接口注入II.
假设A类的某个地方需要用到B类的实例,就是说A类依赖于B类,这时候我们称B类为一个服务,它为A类提供一种服务.
Ioc的做法是: 把B类的实例通过参数的形式传给A类,而不是在A类中直接实例化B类,以消除这种类对某个具体服务的依赖,就这么回事!
当然, B类继承于某个基类或实现了某个接口,B是以其基类或接口的形式传给A类的,
要不然依赖依然存在!
其实,不管是哪种形式,B类的实例都是通过参数的方式传给A类的(构造子参数,接口方法的参数,Setter方法的参数).
构造B类实例的工作就交给ServiceLocator或Assembler了,而这个工作是根据某种配置(代码配置如CommonData或XML配置文件)信息去按照开发者/使用者的意愿去构造一个合适的B类实例.关于如何提供配置信息到对象的映射,那就是各个Ioc框架的事情.其实以前的托管容器式持久性框架就是一个简单Ioc框架,只是没有严格定义"依赖必须分离",而且也只用在了数据访问上了.以前我就自己写了个很好用的托管容器式持久性框架,只是那时还没有Ioc的概念,托管指的其实就是依赖托给容器管理,容器根据配置信息来管理依赖!

这样,这些依赖关系最后就表现在那些配置信息中了.这样做有很多好处:
1.整个应用的所有服务组件都是可插拔的,可替换的,因为他们都是通过接口/基类去提供服务的,只要接口/基类还在,整个应用就可以编译通过.这样才实现了真正灵活的组建化,模块化,服务化!实现真正的松耦合. SOA(面向服务)和AOA(面向切面)的思想其实也都是这个目的:松耦合,可插拔,可替换,模块化.

2.由于每个具体的服务都是松耦合,可插拔可替换的,那么也就是更加易于测试的,因为可以很简单地单独地为某个服务做测试--它不依赖于其他的具体服务,我们可以简单地模拟它需要的服务以做测试.我们也可以在某个服务或某些服务尚未编写的情况下测试这个应用,因为尚未完成的服务都可以模拟. 关于如何提供服务的模拟,那就是各个测试框架的事情. Ioc的红火很大程度上就是因为它使开发和测试都更加的容易进行,效率更高,软件开发过程更加易于管理.特别是著名的"红/绿/重构"的开发过程.这也是MVC的基础,XP(极限编程的核心思想)以及TDD(测试驱动的开发)和MDD(模块驱动的开发)的核心思想!

软件开发离不开软件测试,在未来的软件开发领域,没经过正规的标准的测试流程的软件是站不住脚的. 软件行业生产力的提高最重要的三个因素就是:
开发效率的提高,测试效率的提高和管理效率的提高!

从微软的ASP.NET MVC的开发计划确定下来的那天起,整个软件行业基本上就是更先进的软件开发思想的天下了!这时趋势所在!

从软件行业的发展来看,开放的开源的总是走在生产力的前沿,封闭的总是要落后,因为开源和开放总是聚合着全社会的智慧的.
ORM,反射,Ioc,MVC......开源的JAVA都是走在前面.

人类的思想成果都是使得生产力向前发展的力量,我们看到,Ioc的设计模式是当下流行的几乎所有构架和软件开发思想的基础和核心,如Spring,Castle Windsor,MVC,TDD, MDD,XP,SOA,AOA.
其实思想早就存在,只是在普遍需要的时候才正式地提出来.
IT界的新名词太多,从根本上理解其思想和内涵才是关键!