如何处理Spring / EJB / Mockito…代理上的内部调用？

Question

众所周知，代理对象时，例如为Spring /
EJB创建具有事务属性的Bean时，甚至当您使用某些框架创建部分模拟时，代理对象都不知道，内部调用也不会重定向，然后也没有被拦截…

这就是为什么如果您在Spring中做类似的事情：

@Transactionnal
public void doSomething() {
    doSomethingInNewTransaction();
    doSomethingInNewTransaction();
    doSomethingInNewTransaction();
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void doSomethingInNewTransaction() {
    ...
}

当您致电doSomething时，您希望除了主要交易外还有3个新交易，但是实际上，由于这个问题，您只会得到一个新交易…

所以我想知道您如何处理此类问题…

实际上，我处于必须处理复杂的交易系统的情况，并且没有比将我的服务拆分为许多小型服务更好的方法了，因此我肯定会通过所有代理…

这让我很困扰，因为所有代码都属于同一个功能域，不应拆分。

RobH说，我们可以将spring代理注入服务中，然后调用proxy.doSomethingInNewTransaction（）;。代替。这很容易做到并且有效，但是我真的不喜欢它。

侯云峰这样说：

因此，我编写了自己的CglibSubclassingInstantiationStrategy版本和代理创建器，以便它将使用CGLIB生成一个真正的子类，该子类将调用委托给其父类而不是Spring正在进行的另一个实例。因此，我可以随意注释任何方法（只要它不是私有的），无论我从哪里调用这些方法，都将得到照顾。好吧，我仍然要付出代价：1.我必须列出要启用新的CGLIB子类创建的所有注释。2.由于我现在正在生成子类，因此无法注释final方法，因此无法截获final方法。

他所说的“现在正在春天”是什么意思？这是否意味着现在就拦截了内部事务调用？

您认为哪个更好？

当您需要某种事务粒度时，您是否拆分班级？还是您使用上述类似的解决方法？（请分享）

Answer 1

我将讨论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。

根本不要使用@Transactional

重构代码以使用手动事务划分-可能使用装饰器模式。

一种选择-但是需要适度的重构，引入额外的框架联系和增加的复杂性-因此可能不是首选

我的建议

通常，拆分代码是最好的答案，对于分离关注点也可能是一件好事。但是，如果我有一个严重依赖嵌套事务的框架/应用程序，我会考虑使用AspectJ允许自调用。