您在生产软件中使用AOP（面向方面编程）吗？
在我看来，AOP 是一个有趣的编程范例。 然而，stackoverflow 上还没有关于它的讨论（至少我找不到它们）。 您总体上对此有何看法？ 你的项目中使用AOP吗？ 或者您是否认为它是一项小众技术，不会存在很长时间或不会成为主流（就像 OOP 那样，至少在理论上是这样；））？
如果您确实使用 AOP，请让我们知道您还使用哪些工具。 谢谢！
AOP is an interesting programming paradigm in my opinion. However, there haven't been discussions about it yet here on stackoverflow (at least I couldn't find them). What do you think about it in general? Do you use AOP in your projects? Or do you think it's rather a niche technology that won't be around for a long time or won't make it into the mainstream (like OOP did, at least in theory ;))?
If you do use AOP then please let us know which tools you use as well. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我在 C# 应用程序中大量使用 AOP。 我不太喜欢使用属性，所以我使用 Castle DynamicProxy 和 Boo 在运行时应用方面，而不会污染我的代码
I use AOP heavily in my C# applications. I'm not a huge fan of having to use Attributes, so I used Castle DynamicProxy and Boo to apply aspects at runtime without polluting my code
我们在会话外观中使用 AOP 为客户提供一致的框架来定制我们的应用程序。 这使我们能够公开单点自定义，而无需为每个方法添加手动挂钩支持。
此外，AOP 还为额外的事务设置和拆卸以及常见的日志记录提供了单点配置。 总而言之，这比手动完成所有这些工作更易于维护。
We use AOP in our session facade to provide a consistent framework for our customers to customize our application. This allows us to expose a single point of customization without having to add manual hook support in for each method.
Additionally, AOP provides a single point of configuration for additional transaction setup and teardown, and the usual logging things. All told, much more maintainable than doing all of this by hand.
我工作的主要应用程序包括一个脚本主机。 AOP 允许主机在决定是否将脚本加载到应用程序域之前检查脚本的属性。 由于某些脚本非常麻烦，这使得运行时加载速度更快。
我们还使用并计划使用大量属性来进行编译器控制、流程控制和 IDE 内调试等操作，这些属性不需要成为最终分布式应用程序的一部分。
The main application I work on includes a script host. AOP allows the host to examine the properties of a script before deciding whether or not to load the script into the Application Domain. Since some of the scripts are quite cumbersome, this makes for much faster loading at run-time.
We also use and plan to use a significant number of attributes for things like compiler control, flow control and in-IDE debugging, which do not need to be part of the final distributed application.
我们使用 PostSharp 作为我们的 AOP 解决方案。 我们目前使用缓存、错误处理和数据库重试方面，并且正在将安全检查作为一个方面。
对我们来说效果很好。 开发人员确实喜欢关注点分离。 架构师非常喜欢将平台级逻辑整合到一个位置。
PostSharp 库是一个后编译器，用于执行代码注入。 它有一个预定义的拦截库，很容易实现。 感觉就像在事件处理程序中进行连接。
We use PostSharp for our AOP solution. We have caching, error handling, and database retry aspects that we currently use and are in the process of making our security checks an Aspect.
Works great for us. Developers really do like the separation of concerns. The Architects really like having the platform level logic consolidated in one location.
The PostSharp library is a post compiler that does the injection of the code. It has a library of pre-defined intercepts that are brain dead easy to implement. It feels like wiring in event handlers.
是的，我们在应用程序编程中确实使用了AOP。 我更喜欢使用 AspectJ 将 aop 集成到我的 Spring 应用程序中。 看看这篇文章，以获得更广泛的前景。
http://codemodeweb.blogspot.in/2018/ 03/spring-aop-and-aspectj-framework.html
Yes, we do use AOP in application programming . I preferably use AspectJ for integrating aop in my Spring applications. Have a look at this article for getting a broader prospective for the same.
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html
是的。
正交问题（例如安全性）最好通过 AOP 式拦截来完成。 无论是自动完成（通过依赖注入容器之类的东西）还是手动完成，对于最终目标来说并不重要。
一个例子：xUnit.net（我运行的一个开源项目）中的“before/after”属性是AOP 风格的方法拦截的一种形式。 您可以使用这些属性来装饰您的测试方法，并且在该测试方法运行之前和之后，您的代码将被调用。 它可用于设置数据库和回滚结果、更改测试运行的安全上下文等。
另一个例子：ASP.NET MVC 也像专门的 AOP 风格的方法拦截器一样。 例如，其中之一允许您说明如果未处理的错误发生在您的操作方法中，则应如何处理它们。
许多依赖项注入容器（包括 Castle Windsor 和 Unity）都“内置”或通过使用扩展来支持此行为。
Yes.
Orthogonal concerns, like security, are best done with AOP-style interception. Whether that is done automatically (through something like a dependency injection container) or manually is unimportant to the end goal.
One example: the "before/after" attributes in xUnit.net (an open source project I run) are a form of AOP-style method interception. You decorate your test methods with these attributes, and just before and after that test method runs, your code is called. It can be used for things like setting up a database and rolling back the results, changing the security context in which the test runs, etc.
Another example: the filter attributes in ASP.NET MVC also act like specialized AOP-style method interceptors. One, for instance, allows you to say how unhandled errors should be treated, if they happen in your action method.
Many dependency injection containers, including Castle Windsor and Unity, support this behavior either "in the box" or through the use of extensions.
我不明白如何在不使用 AOP 的情况下以干净的方式处理横切问题，例如日志记录、安全性、事务管理、异常处理。
任何使用 Spring 框架的人（可能大约 50% 的 Java 企业开发人员）都在使用 AOP，无论他们是否知道。
I don't understand how one can handle cross-cutting concerns like logging, security, transaction management, exception-handling in a clean fashion without using AOP.
Anyone using the Spring framework (probably about 50% of Java enterprise developers) is using AOP whether they know it or not.
在 Terracotta 中，我们广泛使用 AOP 和字节码检测来与第三方软件集成并检测第三方软件。 例如，我们的 Spring 集成很大程度上是通过使用 aspectwerkz。 简而言之，我们需要在不同点拦截对 Spring bean 和 bean 工厂的调用，以便对它们进行集群。
因此，AOP 对于与无法修改的第三方代码集成非常有用。 但是，我们发现存在一个巨大的陷阱 - 如果可能，请仅在连接点中使用第三方公共 API，否则您的代码可能会因在下一个次要版本中对某些私有方法的更改而被破坏，并且它会变成维护噩梦。
At Terracotta we use AOP and bytecode instrumentation pretty extensively to integrate with and instrument third-party software. For example, our Spring intergration is accomplished in large part by using aspectwerkz. In a nutshell, we need to intercept calls to Spring beans and bean factories at various points in order to cluster them.
So AOP can be useful for integrating with third party code that can't otherwise be modified. However, we've found there is a huge pitfall - if possible, only use the third party public API in your join points, otherwise you risk having your code broken by a change to some private method in the next minor release, and it becomes a maintenance nightmare.
AOP 和事务划分是天作之合。 我们使用 Spring AOP @Transaction 注释，它比我在其他地方见过的更容易、更直观的 tx 划分。
AOP and transaction demarcation is a match made in heaven. We use Spring AOP @Transaction annotations, it makes for easier and more intuitive tx-demarcation than I've ever seen anywhere else.
我们在我的一个大项目中使用了aspectJ相当长一段时间。 该项目由多个Web服务组成，每个服务都有多种功能，是复杂文档处理/查询系统的前端。 大约有 75k 行代码。 我们将方面用于两个相对较小的功能。
首先是跟踪应用程序流程。 我们创建了一个方面，在每个函数调用之前和之后运行，以打印出“进入‘函数’”和“退出‘函数’”。 通过函数选择器（也许是切入点？我不记得正确的名称），我们可以将其用作调试工具，仅选择我们想要在给定时间跟踪的函数。 这对于我们项目中的各个方面来说是一个非常好的用途。
我们做的第二件事是应用程序特定的指标。 我们围绕 Web 服务方法放置一些方面来捕获计时、对象信息等并将结果转储到数据库中。 这很好，因为我们可以捕获这些信息，但仍然将所有捕获代码与完成工作的“真实”代码分开。
我读过有关方面可以带来的一些不错的解决方案，但我仍然不相信它们真的可以做任何你用“普通”技术做不到的事情（也许更好）。 例如，我想不出我们的任何项目所需的任何主要特性或功能如果没有方面就无法轻松完成 - 我发现方面有用的是我提到的那种小事情。
We used aspectJ in one of my big projects for quite some time. The project was made up of several web services, each with several functions, which was the front end for a complicated document processing/querying system. Somewhere around 75k lines of code. We used aspects for two relatively minor pieces of functionality.
First was tracing application flow. We created an aspect that ran before and after each function call to print out "entered 'function'" and "exited 'function'". With the function selector thing (pointcut maybe? I don't remember the right name) we were able to use this as a debugging tool, selecting only functions that we wanted to trace at a given time. This was a really nice use for aspects in our project.
The second thing we did was application specific metrics. We put aspects around our web service methods to capture timing, object information, etc. and dump the results in a database. This was nice because we could capture this information, but still keep all of that capture code separate from the "real" code that did the work.
I've read about some nice solutions that aspects can bring to the table, but I'm still not convinced that they can really do anything that you couldn't do (maybe better) with "normal" technology. For example, I couldn't think of any major feature or functionality that any of our projects needed that couldn't be done just as easily without aspects - where I've found aspects useful are the kind of minor things that I've mentioned.
Python 通过允许您在运行时动态修改其类来支持 AOP（在 Python 中通常称为 Monkeypatching 而不是 AOP）。 以下是我的一些 AOP 用例：
我有一个网站，其中每个页面都是由 Python 函数生成的。 我想参加一门课程，并对该课程生成的所有网页进行密码保护。 AOP 来救援； 在调用每个函数之前，我会进行适当的会话检查，并在必要时进行重定向。
我想在程序的实际使用过程中对程序中的一堆函数进行一些日志记录和分析。 AOP 允许我计算计时并将数据打印到日志文件，而无需实际修改任何这些函数。
我有一个充满非线程安全函数的模块或类，我发现自己在一些多线程代码中使用它。 一些 AOP 在这些函数调用周围添加锁定，而无需进入库并更改任何内容。
这种事情并不经常出现，但每当出现时，monkeypatching 就非常有用。 Python 还具有实现装饰器设计模式的装饰器 (http://en.wikipedia.org/wiki/Decorator_pattern< /a>) 来完成类似的事情。
请注意，动态修改类还可以让您解决错误或向第三方库添加功能，而无需实际修改该库。 我几乎从来不需要这样做，但它出现的几次都非常有用。
Python supports AOP by letting you dynamically modify its classes at runtime (which in Python is typically called monkeypatching rather than AOP). Here are some of my AOP use cases:
I have a website in which every page is generated by a Python function. I'd like to take a class and make all of the webpages generated by that class password-protected. AOP comes to the rescue; before each function is called, I do the appropriate session checking and redirect if necessary.
I'd like to do some logging and profiling on a bunch of functions in my program during its actual usage. AOP lets me calculate timing and print data to log files without actually modifying any of these functions.
I have a module or class full of non-thread-safe functions and I find myself using it in some multi-threaded code. Some AOP adds locking around these function calls without having to go into the library and change anything.
This kind of thing doesn't come up very often, but whenever it does, monkeypatching is VERY useful. Python also has decorators which implement the Decorator design pattern (http://en.wikipedia.org/wiki/Decorator_pattern) to accomplish similar things.
Note that dynamically modifying classes can also let you work around bugs or add features to a third-party library without actually having to modify that library. I almost never need to do this, but the few times it's come up it's been incredibly useful.