Service @ translation异常翻译

Question

我有一个具有如下操作的web服务

public Result checkout(String id) throws LockException;

执行情况如下：

@Transactional
public Result checkout(String id) throws LockException {
    someDao.acquireLock(id); // ConstraintViolationException might be thrown on commit
    Data data = otherDao.find(id);
    return convert(data);
}

我的问题是，锁定只能在事务提交时失败，而事务提交发生在我的服务方法之外，因此我没有机会将ConstraintViolationException转换为自定义LockException。

备选案文1

建议的一个选项是将服务委托给另一个方法，即@Transactional。例如。

public Result checkout(String id) throws LockException {
    try {
        return someInternalService.checkout(id);
    }
    catch (ConstraintViolationException ex) {
        throw new LockException();
    }
}

...

public class SomeInternalService {
    @Transactional
    public Result checkout(String id) {
        someDao.acquireLock(id);
        Data data = otherDao.find(id);
        return convert(data);
    }
}

我对此的看法是：

• 外部服务尚未使用的内部服务没有合理的名称，因为它们本质上是在做相同的事情。这似乎是一个糟糕的设计指标。
• 如果我想在另一个地方重用someInternalService.checkout，那么这个契约是错误的，因为不管它使用什么，它都可以得到一个ConstraintViolationException。

选项2

我想也许可以使用AOP来在转换异常的服务周围提供建议。但是，这在我看来是错误的，因为checkout需要声明它抛出LockException供客户机使用，但是实际的服务不会抛出它，而是会被通知抛出。没有什么可以阻止将来有人将throws LockException从接口中删除，因为它似乎是不正确的。

而且，这种方法很难测试。如果不创建spring上下文并在测试期间使用AOP，我就无法编写验证抛出异常的JUnit测试。

选项3

在checkout中使用手动事务管理？我不太喜欢这一点，因为应用程序中的其他内容都是使用声明式样式的。

有人知道处理这种情况的正确方法吗？

Answer 1

没有一条正确的路。

你还有几个选择：

1. 使DAO事务性-这不是很好，但可以工作。
2. 创建一个包装服务--称为Facade --其工作是在您提到的事务服务周围执行异常处理/包装--这是关注点的明确分离，并且可以与真正的低级服务共享方法名称。