我将讨论Spring和@Transactional，但该建议也适用于许多其他框架。
这是基于代理的方面的固有问题。在spring文档中对此进行了讨论：
http://static.springsource.org/spring/docs/3.0.x/spring-framework- reference/html/aop.html#aop-understanding-aop- proxies
有许多可能的解决方案。
Spring文档将其描述为 “最佳方法（此处最好使用术语“最佳”）” 。
这种方法的优点是它的简单性，并且与任何框架都没有关系。但是，这可能不适用于事务性很强的代码库，因为您最终会遇到许多琐碎的小类。
这可以通过注入代理或使用硬编码的“AopContext.currentProxy（）”调用来完成（请参见上面的Spring文档。）。
该方法使您避免拆分类，但是在许多方面都抵消了使用事务注释的优势。我个人认为这是有些丑陋的事情之一，但丑陋是自给自足的，如果使用大量交易，这可能是实用的方法。
由于AspectJ不使用代理，因此自调用不是问题
但是，这是一种非常干净的方法-以引入另一个框架为代价。由于这个原因，我从事了一个大型项目，其中引入了AspectJ。
重构代码以使用手动事务划分-可能使用装饰器模式。
一种选择-但是需要适度的重构，引入额外的框架联系和增加的复杂性-因此可能不是首选
通常，拆分代码是最好的答案，对于分离关注点也可能是一件好事。但是，如果我有一个严重依赖嵌套事务的框架/应用程序，我会考虑使用AspectJ允许自调用。
602392714
清零编程群