Guice对AspectJ

Question

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

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

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

在AspectJ之上有哪些Guice特性可以阻止我放弃Guice？

为什么谷歌不放弃Guice而使用AspectJ呢？

副Versa，除了AspectJ的直观性之外，它的哪些特性会鼓励我放弃Guice？

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

Note：要想触发愉快的删除(Azilla)，我意识到这个问题可能过于笼统--但如果我知道要问什么更多的细节，那么我甚至不需要问谷歌/必应( google/bing )我不知道的内容。正如你所看到的，我的Guice知识已经严重退化，以至于我甚至认不出我自己的笔迹。

Answer 1

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

至于为什么AspectJ没有合并到Java中.我不觉得很多人会希望那样的事情发生。AOP很强大，但以一种危险的方式。虽然这对于某些用途来说确实很棒，并且在这些情况下可以大大简化代码，但如果过度使用，可能会使理解程序中发生的事情更加困难。

Answer 2

据我说，AspectJ和Guice做了不同的事情。

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

如果您使用spring，那么使用Guice确实没有什么价值，因为有太多的重叠，然后Spring/AspectJ的共生是一个引人注目的解决方案。

我个人喜欢guice更适合非春季项目，因为它的重量较轻。

Answer 3

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

Guice是一个依赖注入引擎。

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

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

应该指出的是，Spring除了支持AspectJ之外，还支持自己的基于截取程序的AOP，它不需要字节代码操作。