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

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

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

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

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

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

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

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

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

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