Guice vs AspectJ

Posted 2023-02-22

【中文标题】Guice vs AspectJ

【英文标题】：

【发布时间】：2011-04-01 08:38:04

【问题描述】：

几个月前我在使用 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 知识退化得如此之大，以至于我什至认不出自己的笔迹。

【问题讨论】：

我一直有同样的感觉。如果我有 AspectJ，为什么还要使用依赖注入框架？

【参考方案1】：

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

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

【参考方案2】：

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

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

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

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

【参考方案3】：

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

Guice 是一个依赖注入引擎。

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

看到区别了吗？ Guice 和 AspectJ 将是互补的； Spring 已经拥有这两者。

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

【讨论】：

Guice 包含自己的 AOP 支持：code.google.com/p/google-guice/wiki/AOP

不知道；谢谢。看起来像 Spring 的方法拦截器。它是 Bob Lee 原始 Guice 的一部分，还是在首次发布后添加的？

AbstractModule.bindInterceptor 是 Guice 1.0 的一部分。