我记得在 1990 年代末和 2000 年代初，面向方面的编程 (AOP) 被认为是“下一件大事”。现在我看到一些 AOP 仍然存在，但它似乎已经消失在背景中。
BubbaT
问问题
3534 次
5 回答
41
2000 年代初期可能有很多炒作，发生的情况如下：有很多尝试创建面向方面的框架，这些尝试合并到 Java 领域的两个重要项目中：AspectJ 和弹簧 AOP。AspectJ 是完整的、复杂的、学术的、有点过度设计的。Spring AOP 涵盖了 80% 的用例，具有 20% 的复杂性。
如果您查看 Google 趋势中的术语“AspectJ, Spring AOP”，然后与 Java 本身的流行度相比，您会发现 AspectJ 的相对流行度有些恒定，但 Spring AOP 正在提高。这意味着人们使用 AOP，但不想要 AspectJ 的复杂性。我认为 AspectJ 的创造者犯了很多战术错误；AspectJ 一直是一个研究项目，并不是为“大众”设计的。
在 .NET 领域，我们在 2000 年代初看到了对 AOP 的类似兴趣。2003年我开始做AOP研究的时候，.NET的AOP编织者有五六家；所有人都在遵循 AspectJ 的道路，并且都处于婴儿阶段。这些项目都没有幸存下来。基于这个分析，我构建了 PostSharp，它旨在以 20% 的复杂性覆盖 80% 的用例，但使用起来比 Spring AOP 方便得多。PostSharp 现在被认为是 .NET 的主要方面编织器。PostSharp 2.0 建立在 AspectJ 5 年的反馈和行业经验的基础上，并带来了“企业就绪”的 AOP（未来将判断这种说法是否值得）。除了 PostSharp，其他重要的参与者是 Spring Framework for .NET 和 Windsor Castle，这两个以 DI 为中心的应用程序框架提供“也” 方面（方面被视为注入到构造对象中的依赖项）。由于这些技术使用运行时编织，它们具有严重的技术限制，因此实际上它们只能用于服务对象（这就是这些应用程序框架的设计目的）。.NET 中的另一个启动项目是 LinFu，它可以做“也”方面。
简而言之，AOP 格局在去年经历了一些整合，并且可能进入生产力阶段：客户会使用它，因为它真的很省钱，而不是因为它很酷。即使它很酷:)。
哦，我忘了：大多数应用服务器都内置了对 AOP 的支持。想想 JBoss、WebSphere，在某种程度上，还有 WCF。
于 2009-11-20T13:31:29.213 回答
5
每一件“下一件大事”都会发生这种情况。大量炒作，随后流行语的使用缓慢下降。但是，即使流行语逐渐消失并最终消失，它们背后的任何好想法往往都会留下来被主流所吸收。
[编辑] 好的，对于那些认为我在“抨击”某些东西，或者声称面向方面的编程将会消失的人来说，这是一个例子。有一次，下一件大事是结构化编程。面向对象的编程就是从那里发展而来的，现在没有人再谈论做“结构化编程”了。但是，在许多方面，我们仍在使用它最好的想法，因为 OOP 采用了它们，改进了它们，并添加了更多新的想法。
于 2008-11-25T02:08:19.310 回答
5
它存在于一些项目中，我自己在最近的一个项目中的经验是太容易被滥用:( !!! 什么开始了一个很好的方式来设置调试，定时和扩展事务管理，它很快就被破坏到最奇怪的地步，以及我在一段时间内看到的最难理解和调试的代码。
只是为了在调试/诊断方面进行一些扩展，AOP 代码生成的堆栈跟踪多次隐藏了异常发生的实际位置，无法识别。
于 2008-11-25T02:24:10.323 回答
4
AOP 实际上非常出色，它的问题是没有现有的语言对其提供真正强大的支持。当然 C# 具有属性（仅在您对事物进行编码时才有效），而 Java 具有“注入”（这会在运行时造成混乱），但总的来说，没有（主流）语言能够真正很好地支持它。 ..
所以它有点像最终成为一种“设计模式”（尽管在所有不同的语言中都有非常不同的实现），毕竟我猜这并不是那么糟糕；）
于 2008-11-25T02:26:28.667 回答
2
我会建议它还不够大。这听起来很吸引人，但它真的让编码变得更容易了吗？我一直想尝试一下，找出它真正有什么好处，但我认为我在需要它提供的关系的地方做的编码不够。我不认为它像听起来那么有益。
同样在这一点上，让多核编程变得更容易是一件大事，我认为面向方面的编程不会对此有所帮助。
您还可以在Adoption Risks上找到很多内容。
于 2008-11-25T02:23:36.130 回答