我记得在20世纪90年代末和21世纪初，面向方面编程（AOP）被认为是“下一件大事”。现在我看到一些AOP仍然存在，但它似乎已经逐渐消失。
答案 0 :(得分：36)
在2000年代早期可能有很多炒作，发生的事情如下：已经有很多尝试创建面向方面的框架，这些尝试已经合并到Java领域的两个重要项目中：AspectJ和Spring 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，它设计用于覆盖80％的用例，复杂度为20％，但使用起来比Spring AOP更方便。 PostSharp现在被认为是.NET的主要方面。 PostSharp 2.0建立在5年的反馈和AspectJ的行业经验之上，并带来了“企业就绪”的AOP（未来将判断这种说法是否值得）。除了PostSharp，其他重要的参与者是Spring Framework for .NET和Windsor Castle，两个以DI为中心的应用程序框架提供“也”方面（方面被视为注入构造对象的依赖项）。由于这些技术使用运行时编织，因此它们具有严重的技术限制，因此实际上它们只能用于服务对象（这就是这些应用程序框架的设计目的）。 .NET中的另一个启动项目是LinFu，它可以做“也”方面。
简而言之，去年AOP环境经历了一些整合，并可能进入生产阶段：客户将使用它，因为它真的可以省钱，而不是因为它很酷。即使它很酷:)。
哦，我忘记了：大多数应用服务器都内置了对AOP的支持。考虑JBoss，WebSphere，以及某种程度上的WCF。
答案 1 :(得分：5)
每一个“下一件大事”都会发生这种情况。大量的炒作，随后使用流行语的速度缓慢下降。但是，尽管流行语逐渐消失并最终消失，但无论背后有什么好主意，都倾向于坚持主流。
[编辑]好的，那些认为我在“抨击”某些内容或声称面向方面编程的人将会消失的例子。下一个重要的事情是结构化编程。面向对象的编程就是这样的，现在没有人谈论关于进行“结构化编程”了。但是，在很多方面我们仍在使用其最好的想法，因为OOP采用了它们，对它们进行了改进，并添加了更多新想法。
答案 2 :(得分：5)
这是关于某些项目，我自己在最近的一个项目上的经验是太容易滥用:( !!!什么开始一个很好的方式来设置调试，时间和一些扩展事务管理，它很快就被破坏了我在一段时间内看到的最奇怪，最难以理解和调试的代码。
只是为了在调试/诊断方面进行扩展，AOP代码生成的堆栈跟踪多次隐藏在识别异常发生的实际位置之外。
答案 3 :(得分：5)
AOP实际上非常出色，它的问题在于没有现有的语言真正支持伟大的。当然C＃有属性（只有在你编写东西时才有效）和Java有“注入”（它会在运行时产生混乱），但一般来说没有（主流）语言对它有很大的支持。 ..
所以有点像最终成为一个“设计模式”（虽然在所有不同的语言中实现了截然不同的实现），毕竟这不是那么糟糕我想;）
答案 4 :(得分：2)
我会建议它不够大。这听起来很吸引人，但它真的能让编码变得更容易吗？我一直想尝试一下，发现它真正有什么好处，但我不认为我在需要它提供的关系的地方做足够的编码。我认为它听起来不那么有益。
此时，让更容易进行多核编程变得更容易是一件大事，我不认为面向方面的编程会对此有所帮助。
您还可以在Adoption Risks找到大量内容。