您在生产软件中使用 AOP（面向方面编程）吗？答案

【问题标题】：Do you use AOP (Aspect Oriented Programming) in production software?您在生产软件中使用 AOP（面向方面编程）吗？
【发布时间】：2010-09-06 10:43:09
【问题描述】：

AOP 在我看来是一个有趣的编程范式。但是，在stackoverflow上还没有讨论过它（至少我找不到它们）。你一般怎么看？你在你的项目中使用 AOP 吗？还是您认为它是一种不会出现很长时间或不会成为主流的利基技术（就像 OOP 那样，至少在理论上 ;)）？

如果您确实使用 AOP，请告诉我们您还使用了哪些工具。谢谢！

【问题讨论】：

标签： aop paradigms

【解决方案1】：

我不明白如何在不使用 AOP 的情况下以一种干净的方式处理诸如日志记录、安全性、事务管理、异常处理等横切关注点。

任何使用 Spring 框架的人（大约 50% 的 Java 企业开发人员）都在使用 AOP，无论他们是否知道。

【讨论】：

您介意解释一下如何 Log([arguments]) 不干净吗？它会造成什么问题？
@Pacerier，刚刚通过查看一些文档来迟到了 :) .... 有些人认为你不应该写那些句子，这不是干净的意思：与问题无关你打算解决。

【解决方案2】：

是的，我们确实在应用程序编程中使用了 AOP。我最好使用 AspectJ 在我的 Spring 应用程序中集成 aop。看看这篇文章以获得更广泛的前景。

http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html

【讨论】：

【解决方案3】：

我们将 PostSharp 用于我们的 AOP 解决方案。我们目前正在使用缓存、错误处理和数据库重试方面，并且正在将我们的安全检查作为一个方面。

非常适合我们。开发人员真的很喜欢关注点分离。架构师非常喜欢将平台级逻辑整合到一个位置。

PostSharp 库是一个执行代码注入的后编译器。它有一个预定义的拦截库，易于实现。感觉就像在事件处理程序中接线。

【讨论】：

【解决方案4】：

我使用的主要应用程序包括一个脚本主机。 AOP 允许主机在决定是否将脚本加载到应用程序域之前检查脚本的属性。由于某些脚本非常繁琐，因此可以在运行时加快加载速度。

我们还使用并计划将大量属性用于编译器控制、流控制和 IDE 内调试等，这些属性不需要成为最终分布式应用程序的一部分。

【讨论】：

【解决方案5】：

我们在会话外观中使用 AOP 为我们的客户提供一致的框架来定制我们的应用程序。这允许我们公开单点自定义，而无需为每个方法添加手动挂钩支持。

此外，AOP 为额外的事务设置和拆卸以及通常的日志记录提供了单点配置。总而言之，比手动完成所有这些操作更易于维护。

【讨论】：

【解决方案6】：

AOP 和事务划分是天作之合。我们使用 Spring AOP @Transaction 注释，它使 tx-demarcation 比我在其他任何地方看到的更容易和更直观。

【讨论】：

【解决方案7】：

在Terracotta，我们非常广泛地使用 AOP 和字节码检测来与第三方软件集成和检测。例如，我们的Spring intergration 很大程度上是通过使用aspectwerkz 完成的。简而言之，我们需要在各个点拦截对 Spring bean 和 bean 工厂的调用，以便对它们进行集群。

因此，AOP 可用于与无法以其他方式修改的第三方代码集成。但是，我们发现存在一个巨大的陷阱 - 如果可能，请仅在您的连接点中使用第三方公共 API，否则您的代码可能会在下一个次要版本中因更改某些私有方法而被破坏，并且它变成维护的噩梦。

【讨论】：

【解决方案8】：

我在 C# 应用程序中大量使用 AOP。我不是必须使用属性的超级粉丝，所以我使用 Castle DynamicProxy 和 Boo 在运行时应用方面而不会污染我的代码

【讨论】：

【解决方案9】：

Python 通过允许您在运行时动态修改其类来支持 AOP（在 Python 中通常称为猴子补丁而不是 AOP）。以下是我的一些 AOP 用例：

我有一个网站，其中每个页面都是由 Python 函数生成的。我想上一堂课，让该课生成的所有网页都受密码保护。 AOP 来救援；在调用每个函数之前，我会进行适当的会话检查并在必要时进行重定向。
我想在程序的实际使用过程中对程序中的一堆函数进行一些日志记录和分析。 AOP 让我可以计算时间并将数据打印到日志文件，而无需实际修改任何这些函数。
我有一个充满非线程安全函数的模块或类，我发现自己在一些多线程代码中使用它。一些 AOP 在这些函数调用周围添加了锁定，而无需进入库并进行任何更改。

这种事情并不经常出现，但无论何时出现，monkeypatching 都非常有用。 Python 也有装饰器，它们实现了装饰器设计模式 (http://en.wikipedia.org/wiki/Decorator_pattern) 来完成类似的事情。

请注意，动态修改类还可以让您解决错误或向第三方库添加功能，而无需实际修改该库。我几乎从不需要这样做，但它出现的几次非常有用。

【讨论】：

【解决方案10】：

是的。

像安全性这样的正交问题最好通过 AOP 样式的拦截来完成。无论是自动完成（通过依赖注入容器之类的东西）还是手动完成对最终目标来说并不重要。

一个例子：xUnit.net（我运行的一个开源项目）中的“before/after”属性是一种AOP风格的方法拦截。您使用这些属性装饰您的测试方法，并且在该测试方法运行之前和之后，您的代码被调用。它可用于设置数据库和回滚结果、更改测试运行的安全上下文等。

另一个例子：ASP.NET MVC 中的过滤器属性也像专门的 AOP 风格的方法拦截器。例如，一个允许您说明未处理的错误应如何处理，如果它们发生在您的操作方法中。

许多依赖注入容器，包括 Castle Windsor 和 Unity，都支持这种行为，要么“在盒子里”，要么通过使用扩展。

【讨论】：

在声称某事是最好的时候要小心。许多专家认为能力模型是实现安全的最佳方式，而 AOP 是一件可怕的事情。
@Brad，你说有些事情最好用 AOP 完成。与传统方式相比，您能确切地解释AOP方式的优势吗？

【解决方案11】：

我们在我的一个大型项目中使用 aspectJ 已经有一段时间了。该项目由多个 Web 服务组成，每个 Web 服务具有多个功能，是复杂文档处理/查询系统的前端。大约 75k 行代码。我们将方面用于两个相对较小的功能。

首先是跟踪应用程序流。我们创建了一个在每个函数调用之前和之后运行的方面，以打印出“输入的‘函数’”和“退出的‘函数’”。使用函数选择器（可能是切入点？我不记得正确的名称）我们能够将其用作调试工具，仅选择我们想要在给定时间跟踪的函数。这对我们项目中的切面来说非常有用。

我们做的第二件事是应用特定的指标。我们围绕我们的 Web 服务方法设置方面来捕获时间、对象信息等，并将结果转储到数据库中。这很好，因为我们可以捕获这些信息，但仍将所有捕获代码与完成工作的“真实”代码分开。

我已经阅读了方面可以带来的一些不错的解决方案，但我仍然不相信它们真的可以做任何你不能用“正常”技术做的事情（也许更好）。例如，我想不出我们的任何项目需要的任何主要特性或功能，如果没有方面就无法轻松完成 - 我发现方面有用的是我提到的那种次要的东西.

【讨论】：

抱歉这些 python 项目？