我将讨论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允许自调用。