Spring的替代方案
回顾我们曾评论过的一些开源项目，我们会发现Spring并不是唯一提供依赖注入功能或从上至下建立应用的框架。事实上，如果仔细想想，有太多这样的框架。本着开放的精神，我们简略地介绍其中的几个，但是我们相信其中没有一个能提供Spring这样丰富的解决方案。
1. PicoContainer
PicoContainer（www.picocontainer.org）是一个特别小（100 kB）的依赖注入容器，允许我们在除了PicoContainer本身不添加任何其他依赖的情况下使用依赖注入。因为PicoContainer就是一个单纯的依赖注入容器，所以我们会发现随着应用的不断扩展，不得不引入另外一个框架（比如Spring），那么如果一开始就用Spring岂不是更好。但是，假若需要的是一个微型的依赖注入容器，PicoContainer则是一个不错的选择。Spring的依赖注入容器包和框架中的其他部分是分离的，我们也可以很容易地只使用本部分，这样又能提供日后的扩展性。
2. NanoContainer
NanoContainer（www.nanocontainer.org）是 PicoContainer的扩展，用于管理独立的PicoContinaer容器。因为Spring也同样提供了所有标准依赖注入容器具有的功能，NanoContainer与Spring比并不占优势。NanoContainer最吸引人的是其对脚本语言的支持，但是目前Spring也完全支持脚本语言。
3. Keel框架
Keel框架（www.keelframework.org）更像是一个元框架，因为它的大部分功能来自于其他框架，并通过它集成在一起。举例来说，它的依赖注入功能来自于Apache Avalon容器，而Web功能来自于Struts或类似的框架。Keel提供了很多相同组件的实现，并把它们集成到一个统一的结构中，这让你能够在对你的应用影响最小的情况下换出实现。尽管Keel的功能很广泛，但是它却并没有像Spring那样受欢迎。尽管我们研究Keel的时间还很短，但是我们认为，这是因为Keel的难度造成的。Spring对于各个层面的开发者来说都能立即使用，相对而言Keel就要复杂得多。话虽如此，Keel的特性还是相当不错的，它毫无疑问是Spring的直接竞争对手。
4. Google Guice
这个Guice（读"juice"）框架只关注于依赖注入。因此，它不是一个直接与Spring竞争的框架。事实上，我们可以在Guice上使用Spring管理bean。除了侧重点不同外，Spring和Guice的主要区别在于应用配置的差异。Guice使用自动装配或基于注解的配置，自动装配意味着框架已经检查了组件部分，并尝试猜测它们之间的依赖关系。这个猜测是基于依赖的类型和名称。因此，即使是Guice的创建者也承认（我们也完全同意）自动装配不适合大型的企业应用。对于复杂的应用来说，Guice的创建者建议使用基于注解的配置。Guice不像Spring，它不需要任何复杂的配置文件。
遗憾的是，使用Guice，我们只能添加Guice的注解。但即使是有这个不足，Guice也同样是一个很好的框架，它最大的优点是可以与Spring一起使用。