随着 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 并不打算解决那些大问题。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论