随着 Guice 的最初发行版慢慢尘埃落定,将它和 Spring IoC ,尤其是和 Spring JavaConfig 进行的比较也随之浮出水面。Guice 和 JavaConfig 采取了两种不同的方式使用 Java Annotations 将 IoC 配置放入代码。
目前 Spring JavaConfig 发布了 1.0 Milestone 1 版本,它和 Guice 的基本想法是一致的——把配置从 XML 移至 Annotation 是一种更好的做法,因为这样使得配置信息与代码更为紧密。 Tapestry 的 IoC 容器也是根据同样的想法设计的。
JavaConfig 和 Guice 的背景极其相似。事实上,Bob Lee 是这样叙述它们的历史的:
此外,我还想说一个有点意思的小故事:Guice 最开始的时候和 Spring JavaConfig 看起来非常像——这并不奇怪,因为 Rod 一年前向我展示了 Spring JavaConfig(而六个月前我又让他看了 Guice)。正如使用 JavaConfig 一样,你得显式地写 Java 代码来连接你的对象。我从一开始就引入 @Inject 做为检查外部代码按照你的安排调用所有的 setters 的一种可选方式。而自打我们有了 @Inject,我开始问,我们为什么还需要显式地编写对象连接代码呢?于是很快我们就有大家今天所知道的 Guice。
关于 Guice 和 JavaConfig 区别的帖子有不少。Debasish Ghosh 恰如其分地总结到:
Guice 和 Spring 之间最主要的区别,可以归结为它们看待依赖关系和配置的哲学之间的差异。Spring 宣扬的是非侵入性的方式,以一种完全外部化的方式来对待对象依赖关系。在 Spring 里,你可以使用 XML、Spring JavaConfig 或者 Groovy-Spring DSL 来连接对象依赖关系,也可以使用其它的方案,如 Spring-annotations。但是,不管你用的是什么技术,依赖关系总是被外部化的。
另一方面,Guice 却把配置做为你的应用程序模型的首要对象来看待,允许它们存在于你的领域模型代码中。我们使用 Guice 模块来说明需要注入什么东西,然后使用 annotations 来指明需要在什么注入。你可以使用注入来标记(annotate)类本深(通过 @Inject annotation)。缺点则是(如果你使者么认为的话)你必须在你的领域模型中引入 com.google.inject.*。但它通过元数据编程(metadata programming)来确保了目标的方向性,以及注入的显式语义。
在这些文章的回帖中,你可以发现,在这两个框架之间做选择的时候,最值得注意的就是它们设计哲学的区别。你会希望依赖注入和代码靠得有多近呢?如果使用 Guice,你的代码将和容器紧密耦合在一起,这样做有些人喜欢,有些人反感。Guice 号称自己的速度更快,但值得注意的是,Spring IoC 容器(不管是 JavaConfig 还是其它)支持多种钩子,而 Guice 并没有提供。Spring 为大家带来的不仅仅是 IoC,而 Guice 并不打算解决那些大问题。
评论