java - Guice vs AspectJ

Question

几个月前我在使用 GUice，现在当我回到它时，我发现我必须重新阅读 Guice 文档和示例才能了解我对我的代码做了什么。

但是，当我查看 AspectJ 时，它太直观了。它是 Java 语言的直观扩展。我觉得我已经可以坐下来立即编写 AspectJ 代码了。

因此，我很想放弃对 Guice 的追求而选择 AspectJ。尤其是 Spring 正在生成 AspectJ 代码这一事实。

在 AspectJ 之上 Guice 的哪些特性会阻止我放弃 Guice？

为什么 Google 不放弃 Guice 而使用 AspectJ？

Vice Versa，除了直观性之外，AspectJ 的哪些功能会鼓励我放弃 Guice？

如果我可以在这里“编织”一个问题，那么是什么阻止了 Java 语言与 AspectJ 合并或在未来的 Java 版本中提供类似的“方面”？

注意：要触发快乐的 delete-azillas，我意识到这个问题可能太笼统了 - 但如果我知道要问什么进一步的细节，那么我什至不需要问，只需 google/bing 就知道我不知道知道。正如你所看到的，我的 Guice 知识已经退化得如此严重，以至于我什至认不出自己的笔迹。

Answer 1

正如彼得所说，Guice 和 AspectJ 是完全不同的东西。Guice 进行依赖注入，节省了大量的工厂编写工作，同时使代码灵活且易于测试，并添加了有用的东西，如作用域。它还碰巧允许通过方法拦截（通过编程配置拦截哪些方法，而不是 DSL）来执行 AOP。这实际上只是它提供的另一个好处，而不是它的核心目标。

至于为什么 AspectJ 没有合并到 Java 中……我不觉得很多人会希望这种情况发生。AOP 很强大，但也很危险。虽然它对于某些用途肯定很棒并且在这些情况下大大简化了代码，但如果过度使用它可能会使理解程序中发生的事情变得更加困难。

Answer 2

据我所知，AspectJ 和 Guice 做不同的事情。

Guice 注入依赖关系，AspectJ 处理横切关注点。

如果您使用 spring，那么使用 Guice 的价值确实较小，因为重叠太多，然后 Spring/AspectJ 的共生是一个令人信服的解决方案。

我个人认为 guice 更适合非弹簧项目，因为它的重量更轻。

Answer 3

Spring 建立在依赖注入和面向方面的编程之上。

Guice 是一个依赖注入引擎。

AspectJ 是一个面向方面的引擎。

看到不同？Guice 和 AspectJ 将是互补的；Spring 已经两者兼备。

值得一提的是，除了 AspectJ 之外，Spring 还支持自己的基于拦截器的 AOP，它不需要字节码操作。