@H_502_2@依赖倒转原则是指导设计两个模块之间的关系的一个设计原则。如下图所示，假设模块A@H_502_2@是我们系统要实现的核心功能，模块B@H_502_2@提供某种事务服务。因为模块A@H_502_2@需要事务服务，所以，一般的设计思想是模块A@H_502_2@要依赖于模块B@H_502_2@。

@H_502_2@

而@H_502_2@依赖倒转原则就是要把这种依赖关系倒转过来。也就是让模块B@H_502_2@依赖于模块A@H_502_2@。

@H_502_2@

@H_502_2@这@H_502_2@样，模块A@H_502_2@的代码实现中，涉及事务的地方，只需要使用接口A@H_502_2@，而接口A@H_502_2@的实现是在运行时被依赖注入到模块A@H_502_2@的程序中去的。这样保证了，模块A@H_502_2@是面向接口进行编程的，从而使得事务服务可被替换；同时保证了模块A@H_502_2@真正专注于核心功能的实现。因此，依赖倒转的实现总是伴随着依赖注入。

@H_502_2@当不使用OSGi@H_502_2@时，我们照样可以实现依赖倒转的设计思想，但是当系统复杂时，很难从程序上判断真正的依赖关系是否是这样的，至少在编译环境下，我们看不出来。而使用OSGi@H_502_2@就解决了这样一个问题。当我们设计模块B@H_502_2@依赖于模块A@H_502_2@时，模块A@H_502_2@是看不到模块B@H_502_2@的任何类的，因此在编译时，就保证了模块A@H_502_2@不依赖于模块B@H_502_2@。

Spring@H_502_2@框架也是基于依赖注入的，但是，OSGi@H_502_2@的依赖注入与Spring@H_502_2@有明显的不同。

Spring@H_502_2@的注入点与被注入对象是通过bean@H_502_2@的id@H_502_2@进行严格匹配的，如下所示：

Component2@H_502_2@声明为要被注入Component1@H_502_2@，是通过ref@H_502_2@标签显式定义的。

@H_502_2@而OSGi@H_502_2@由于是完全动态的，一个要被注入其它对象的Component@H_502_2@，只需要公开声明其所依赖的接口，而实现此接口的对象，则会在运行时动态查找并自动的注入。如果此接口有多个实现Component@H_502_2@，则到底被注入是哪一个？如何确定？这个问题目前我也比较疑惑，毕竟有些情况下我们还是需要能决定OSGi@H_502_2@到底采用哪个Service@H_502_2@的。可能采用过滤器匹配能实现吧。

@H_502_2@估计这也是OSGi@H_502_2@为什么没有“构造函数”注入方式的原因。因为，被注入的对象是在运行时动态匹配和注入的，也就是说在时刻a@H_502_2@，ComponentA@H_502_2@可能被注入了CompomentB@H_502_2@，但是一段时间后，在时刻b@H_502_2@，ComponentB@H_502_2@所在的Bundle@H_502_2@可能被停止了，取而代之的是ComponentC@H_502_2@，那么这时，ComponentA(@H_502_2@注意仍然是原来的对象实例，而非重新new@H_502_2@出来的A)@H_502_2@被注入的就是ComponentC@H_502_2@了。这样，注入的方式只能是通过set@H_502_2@方式了。

@H_502_2@

@H_502_2@@H_502_2@而在Spring@H_502_2@中，存在构造函数注入方式说明了Spring@H_502_2@的容器在初始化Bean@H_502_2@时就把Bean@H_502_2@所需要的都准备好了，而且不可能进行动态的调整。