关于范例:您是否在生产软件中使用AOP(面向方面编程)?

关于范例:您是否在生产软件中使用AOP(面向方面编程)?

Do you use AOP (Aspect Oriented Programming) in production software?

在我看来,AOP是一个有趣的编程范例。 但是,目前还没有关于stackoverflow的讨论(至少我找不到它们)。 你对此有何看法? 你在项目中使用AOP吗? 或者你认为它是一种利基技术,不会长时间存在或者不会成为主流(就像OOP一样,至少在理论上会这样做))?

如果您确实使用AOP,请告诉我们您使用的工具。 谢谢!


Python支持AOP,允许您在运行时动态修改它的类(在Python中通常称为monkeypatching而不是AOP)。以下是我的一些AOP用例:

  • 我有一个网站,其中每个页面都是由Python函数生成的。我想上课,让该课程生成的所有网页都受密码保护。 AOP来救援;在调用每个函数之前,我会根据需要进行适当的会话检查和重定向。

  • 我希望在实际使用过程中对程序中的一些函数进行一些日志记录和分析。 AOP允许我计算时间和打印数据到日志文件而不实际修改任何这些功能。

  • 我有一个充满非线程安全函数的模块或类,我发现自己在一些多线程代码中使用它。一些AOP在这些函数调用周围添加了锁定,而无需进入库并进行任何更改。

  • 这种事情并不常见,但每当它发生时,monkeypatching非常有用。 Python还有装饰器,它们实现了Decorator设计模式(http://en.wikipedia.org/wiki/Decorator_pattern)来完成类似的事情。

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


    是。

    正如安全性一样,正交问题最好用AOP风格的拦截来完成。这是自动完成(通过依赖注入容器之类的东西)还是手动完成对于最终目标而言并不重要。

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

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

    许多依赖注入容器,包括Castle Windsor和Unity,都支持"在框中"或通过使用扩展这种行为。


    我不明白如何在不使用AOP的情况下以干净的方式处理日志记录,安全性,事务管理,异常处理等跨领域问题。

    任何使用Spring框架的人(可能大约有50%的Java企业开发人员)都在使用AOP,无论他们是否知道。


    AOP和交易划分是在天堂进行的比赛。我们使用Spring AOP @Transaction注释,它比我在其他任何地方看到的更容易和更直观的tx划分。


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

    因此,AOP可用于与无法修改的第三方代码集成。但是,我们发现存在一个巨大的缺陷 - 如果可能的话,只在您的连接点中使用第三方公共API,否则您可能会在下一个次要版本中通过更改某些私有方法来破坏您的代码,并且它变为维护噩梦。


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

    首先是跟踪申请流程。我们创建了一个在每个函数调用之前和之后运行的方面,以打印出"输入的'函数'"和"退出的'函数'"。使用函数选择器(切入点可能?我记不起正确的名称)我们可以将它用作调试工具,只选择我们想要在给定时间跟踪的函数。这对我们项目中的方面非常好用。

    我们做的第二件事是特定于应用程序的指标。我们将Web服务方法的各个方面用于捕获时序,对象信息等,并将结果转储到数据库中。这很好,因为我们可以捕获这些信息,但仍然将所有捕获代码与执行工作的"真实"代码分开。

    我已经阅读了一些方面可以带来的好解决方案,但我仍然不相信他们可以用"普通"技术做任何你不能做的事情(可能更好)。例如,我想不出任何我们需要的任何主要特性或功能,如果没有方面就不能轻易完成 - 我发现有用的方面是我提到的那些小问题。


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

    对我们有用。开发人员确实喜欢分离关注点。架构师非常喜欢将平台级逻辑整合到一个位置。

    PostSharp库是一个后编译器,用于注入代码。它有一个预先定义的拦截库,可以很容易地实现脑死亡。感觉就像事件处理程序中的布线一样。


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

    我们还使用并计划在编译器控制,流控制和IDE内调试等方面使用大量属性,这些属性不需要是最终分布式应用程序的一部分。


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

    此外,AOP为其他事务设置和拆卸以及通常的日志记录提供单点配置。总而言之,比手工完成所有这些更加可维护。


    我在C#应用程序中大量使用AOP。我不是必须使用Attributes的忠实粉丝,因此我使用Castle DynamicProxy和Boo在运行时应用方面而不会污染我的代码


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

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


    推荐阅读