在我看来, AOP是一种有趣的编程范式。但是,在 stackoverflow 上还没有关于它的讨论(至少我找不到它们)。您对此有何看法?你在你的项目中使用 AOP 吗?还是您认为它是一种不会出现很长时间或不会成为主流的利基技术(就像 OOP 那样,至少在理论上 ;))?
如果您确实使用 AOP,那么请让我们知道您还使用了哪些工具。谢谢!
Python 通过让您在运行时动态修改其类来支持 AOP(在 Python 中通常称为猴子补丁而不是 AOP)。以下是我的一些 AOP 用例:
我有一个网站,其中每个页面都是由 Python 函数生成的。我想上一堂课,让该课生成的所有网页都受密码保护。AOP 来救援;在调用每个函数之前,我会进行适当的会话检查并在必要时进行重定向。
我想在程序的实际使用过程中对程序中的一堆函数进行一些日志记录和分析。AOP 允许我计算时间并将数据打印到日志文件,而无需实际修改任何这些函数。
我有一个充满非线程安全函数的模块或类,我发现自己在一些多线程代码中使用它。一些 AOP 在这些函数调用周围添加了锁定,而无需进入库并进行任何更改。
这种事情并不经常出现,但无论何时出现,monkeypatching 都非常有用。Python 也有装饰器,它们实现了装饰器设计模式(http://en.wikipedia.org/wiki/Decorator_pattern)来完成类似的事情。
请注意,动态修改类还可以让您解决错误或向第三方库添加功能,而无需实际修改该库。我几乎从不需要这样做,但它出现的几次非常有用。
是的。
正交问题(如安全性)最好使用 AOP 样式的拦截来完成。无论是自动完成(通过依赖注入容器之类的东西)还是手动完成对最终目标来说并不重要。
一个例子: xUnit.net(我运行的一个开源项目)中的“之前/之后”属性是一种 AOP 风格的方法拦截形式。您使用这些属性装饰您的测试方法,并且在该测试方法运行之前和之后,您的代码被调用。它可用于设置数据库和回滚结果、更改测试运行的安全上下文等。
另一个例子: ASP.NET MVC中的过滤器属性也像专门的 AOP 风格的方法拦截器。例如,一个允许您说明如果未处理的错误发生在您的操作方法中,应该如何处理它们。
许多依赖注入容器,包括 Castle Windsor 和 Unity,都支持这种行为,要么“在盒子里”,要么通过使用扩展。
我不明白如何在不使用 AOP 的情况下以一种干净的方式处理诸如日志记录、安全性、事务管理、异常处理等横切关注点。
任何使用 Spring 框架的人(可能大约 50% 的 Java 企业开发人员)都在使用 AOP,无论他们是否知道。
在Terracotta,我们非常广泛地使用 AOP 和字节码检测来与第三方软件集成和检测。例如,我们的Spring集成在很大程度上是通过使用aspectwerkz完成的。简而言之,我们需要在各个点拦截对 Spring bean 和 bean 工厂的调用,以便对它们进行集群。
因此,AOP 可用于与无法以其他方式修改的第三方代码集成。然而,我们发现有一个巨大的陷阱——如果可能,只在你的连接点中使用第三方公共 API,否则你的代码可能会在下一个小版本中被更改为一些私有方法而破坏,它变成维护的噩梦。
AOP 和事务分界是天作之合。我们使用 Spring AOP @Transaction 注释,它使 tx-demarcation 比我在其他任何地方看到的更容易和更直观。
我们在我的一个大项目中使用 aspectJ 已经有一段时间了。该项目由多个 Web 服务组成,每个 Web 服务具有多个功能,是复杂文档处理/查询系统的前端。大约 75k 行代码。我们将方面用于两个相对较小的功能。
首先是跟踪应用程序流。我们创建了一个在每个函数调用之前和之后运行的方面,以打印出“输入的‘函数’”和“退出的‘函数’”。使用函数选择器(可能是切入点?我不记得正确的名称)我们能够将其用作调试工具,仅选择我们想要在给定时间跟踪的函数。这对于我们项目中的方面来说是一个非常好的用途。
我们做的第二件事是应用程序特定的指标。我们围绕我们的 Web 服务方法设置方面来捕获时间、对象信息等,并将结果转储到数据库中。这很好,因为我们可以捕获这些信息,但仍然将所有捕获代码与完成工作的“真实”代码分开。
我已经阅读了方面可以带来的一些不错的解决方案,但我仍然不相信它们真的可以做任何你不能用“正常”技术做的事情(也许更好)。例如,我想不出我们的任何项目需要的任何主要特性或功能,如果没有方面就无法轻松完成 - 我发现方面有用的是我提到的那种次要的东西.
我在 C# 应用程序中大量使用 AOP。我不是必须使用属性的超级粉丝,所以我使用 Castle DynamicProxy 和 Boo 在运行时应用方面而不会污染我的代码
我们在会话外观中使用 AOP 为我们的客户提供一致的框架来定制我们的应用程序。这允许我们公开单点自定义,而无需为每个方法添加手动挂钩支持。
此外,AOP 为额外的事务设置和拆卸以及通常的日志记录提供了单点配置。总而言之,比手动完成所有这些操作更易于维护。
我工作的主要应用程序包括一个脚本主机。AOP 允许主机在决定是否将脚本加载到应用程序域之前检查脚本的属性。由于一些脚本非常繁琐,这使得在运行时加载速度更快。
我们还使用并计划将大量属性用于编译器控制、流控制和 IDE 内调试等,这些属性不需要成为最终分布式应用程序的一部分。
我们将 PostSharp 用于我们的 AOP 解决方案。我们拥有当前使用的缓存、错误处理和数据库重试方面,并且正在使我们的安全检查成为一个方面。
非常适合我们。开发人员真的很喜欢关注点分离。架构师非常喜欢将平台级逻辑整合到一个位置。
PostSharp 库是一个执行代码注入的后编译器。它有一个预定义的拦截库,易于实现。感觉就像在事件处理程序中接线。
是的,我们确实在应用程序编程中使用了 AOP。我最好使用 AspectJ 在我的 Spring 应用程序中集成 aop。看看这篇文章以获得更广泛的前景。
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html