使用 Spring AOP 进行日志记录是一个好主意吗?

发布于 2024-08-17 14:22:18 字数 249 浏览 5 评论 0原文

我现在正在阅读 Spring 的相关内容,使用 AOP 的示例之一是记录方法调用的开始和结束。

我还了解到使用 AOP 会影响性能。

对于这种类型的日志记录,使用 Spring AOP 是一个好主意吗?我的理解是Spring使用动态AOP,对于这种类型的AOP使用静态AOP(如AspectJ)会更好。

目前,我工作的公司的编码政策需要大量的日志记录,我想减少必须编写的日志代码量并提高代码的可读性。

我是不是找错了树?

I'm reading up on Spring at the moment and one of the examples used for a use of AOP is logging the start and end of method calls.

I've also read that using AOP can impact performance.

Is using Spring AOP a good idea for this type of logging? My understanding is that Spring uses Dynamic AOP would it be be better to use Static AOP (Like AspectJ) for this type of AOP.

Curently the coding policy of the company I work for requires a ridiculous amount of logging and i want to reduce the ammount of logging code I have to write and improve the readability of my code.

Am I barking up the wrong tree?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

柏林苍穹下 2024-08-24 14:22:18

我使用 Spring AOP 来实现日志记录,因此我分享我的观察结果:

  • 性能影响不够,它小于日志记录本身的影响
  • 在 Spring 配置中配置了方面,您可以在必要时完全禁用日志记录代码
  • 调试随着堆栈而变得更加成问题走线变得相当长
  • 这样的决定足以影响设计。不仅你得到了一堆接口和方面类,而且你的生产类必须非常“薄”。不要忘记,您无法拦截对非公共方法的调用。自调用(甚至是公共方法)也无法被拦截(因为您使用裸 this 句柄而不是 AOP 包装的句柄),因此无法记录。因此,所有日志记录只能发生在接口边界上。 (这涉及到使用基于代理的切面编织,可以选择使用 cglib 进行运行时子类化,但我没有使用它)
  • 编写切入点可能非常棘手。 IntelliJ Idea 极大地帮助确定切入点建议哪些方法。
  • 总的来说,我喜欢这种方法并且认为它值得使用,但它看起来比我预期的要复杂得多

I used Spring AOP for implementing logging so I share my observations:

  • Performance impact is not sufficient, it is less than impact of logging itself
  • Having aspects configured in Spring configuration, you are able to completely disable logging code if necessary
  • Debugging becomes more problematic as stack traces become rather longer
  • Such decision sufficiently affects design. It is not only that you get a bunch of interfaces and aspect classes, but you production classes must be very "thin". Don't forget, you are unable to intercept calls to non-public methods. Self-calls (even to public methods) also cannot be intercepted (as you working with naked this handle instead of handle wrapped by AOP) and thus cannot be logged. So all logging can happen only on interface boundaries. (This concerns using Proxy-based aspect weaving, there's an option of runtime subclassing with cglib, but I didn't use it)
  • Writing pointcuts can be very tricky. IntelliJ Idea helps greatly determining which methods are to be adviced by pointcut.
  • Generally, I liked this approach and think it is worth using, but it appeared far more complicated than I expected
dawn曙光 2024-08-24 14:22:18

阅读这篇博文了解您的表现的担忧。

AOP 的思考方式是将提供的功能利益放在第一位。如果自动日志记录是您的要求并且 AOP 适合它 - 那就去做吧。

也就是说,如果需要细粒度的日志记录,加载时编织当然是首选。

Read this blog-post about your performance concerns.

The way to think of AOP is to put the provided functional benefits in the first place. If automated logging is your requirement and AOP fits it - go for it.

That said, load-time weaving is, of course, preferred if fine-grained logging is required.

傻比既视感 2024-08-24 14:22:18

我按照这篇博文。这是我发现的最好的,它还有一个 示例,显示得很好使用和不使用AOP的区别。

恕我直言,这是不值得的,除非您正在做一些比日志记录更奇特的事情,例如具有持久性的错误管理。如果您有良好的异常层次结构(域、系统)并正确设置日志记录边界,则不会减少太多日志记录代码。

I did it similarly to the way described in this blog post. It's the best I found and it also has a sample that shows nicely the difference between using and not using AOP.

Imho it isn't worth it, unless you're doing something fancier then logging, like error management with persistence. If you have a good exception hierarchy (domain, system) and properly set logging boundaries, you wont reduce much logging code.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文