我认为事务属于服务层。它了解工作单元和用例。如果将几个dao注入到需要在单个事务中协同工作的服务中，这是正确的答案。

事务注释应该放在所有不可分割的操作周围。

例如，你的呼叫是“change password”。它由两个操作组成

修改密码。 审计变更。 通过电子邮件通知客户端密码已更改。

那么在上面，如果审计失败，那么修改密码也应该失败吗?如果是这样，那么事务应该在1和2左右(因此在服务层)。如果电子邮件失败了(可能应该有某种故障安全措施，这样它就不会失败)，那么它是否应该回滚更改密码和审计?

在决定将@Transactional放在哪里时，您需要询问这些问题。

总的来说，我同意其他人的说法，事务通常在服务级别上启动(当然，这取决于您需要的粒度)。

然而，与此同时，我也开始在我的DAO层(以及其他不允许启动事务但需要现有事务的层)中添加@Transactional(propagation = propagation . mandatory)，因为当您忘记在调用者(例如服务)中启动事务时，检测错误要容易得多。如果您的DAO带有强制传播注释，则会得到一个异常，说明在调用方法时没有活动事务。

我还进行了一个集成测试，在该测试中，我检查了所有bean (bean后处理器)的该注释，如果在不属于服务层的bean中存在传播方式不是Mandatory的@Transactional注释，则会失败。这样可以确保我们不会在错误的层上启动事务。

通常，应该将事务放在服务层。

但是正如前面所述，操作的原子性告诉我们哪里需要注释。因此，如果你使用像Hibernate这样的框架，其中一个“save/update/delete/…”一个对象上的“modify”操作有可能修改几个表中的几行(因为通过对象图的级联)，当然在这个特定的DAO方法上也应该有事务管理。

此外，Spring建议只在具体的类上使用注释，而不是在接口上使用。

http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html

用于数据库级别的事务

大多数情况下，我在DAO的方法级别上使用@Transactional，所以配置可以专门用于一个方法/使用默认值(必需的)

DAO获取数据的方法(select ..)-不需要 @事务性这可能会导致一些开销，因为 事务拦截器/和需要执行的AOP代理 好。 DAO的插入/更新方法将获得@Transactional

非常好的博客

应用级别: 我正在使用事务性业务逻辑，我希望能够在发生意外错误的情况下回滚

@Transactional(rollbackFor={MyApplicationException.class})
public void myMethod(){

    try {    
        //service logic here     
    } catch(Throwable e) {

        log.error(e)
        throw new MyApplicationException(..);
    }
}