Spring的替代方案

1.2.5 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一起使用。

转自:http://book.51cto.com/art/200909/149100.htm

你可能感兴趣的:(spring,框架,struts,脚本,企业应用,扩展)