最好把它放在服务层!这在我昨天看到的一篇文章中有清楚的解释!这是你可以查看的链接!

用于数据库级别的事务

大多数情况下，我在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(..);
    }
}

服务层是添加@Transactional注释的最佳位置，因为这里呈现的大多数业务逻辑都包含细节级用例行为。

假设我们将它添加到DAO，从服务调用2个DAO类，一个失败，另一个成功，在这种情况下，如果@Transactional不在服务上，一个DB将提交，另一个DB将回滚。

因此，我的建议是明智地使用这个注释，只在服务层使用。

Github项目- java-algos

或者对两个“层”都加注释有意义吗?-同时标注服务层和dao层不是很有意义吗-如果你想确保dao方法总是从服务层调用(传播)，并且在dao中传播是“强制的”。这将为DAO方法从UI层(或控制器)调用提供一些限制。此外——特别是在对DAO层进行单元测试时——对DAO进行注释还将确保对其事务功能进行测试。

@Transactional注释应该放在所有不可分割的操作周围。 使用@Transactional可以自动处理事务传播。在这种情况下，如果当前方法调用了另一个方法，那么该方法将可以选择加入正在进行的事务。

让我们举个例子:

我们有两个模型，即国家和城市。国家和城市模型的关系映射就像一个国家可以有多个城市，所以映射就像，

@OneToMany(fetch = FetchType.LAZY, mappedBy="country")
private Set<City> cities;

在这里国家映射到多个城市，获取他们懒惰。这里是@Transactinal的作用当我们从数据库中检索Country对象时，我们会得到Country对象的所有数据，但不会得到城市的集合，因为我们是懒洋洋地获取城市。

//Without @Transactional
public Country getCountry(){
   Country country = countryRepository.getCountry();
   //After getting Country Object connection between countryRepository and database is Closed 
}

当我们想要从国家对象访问Set of Cities时，我们将在该Set中获得空值，因为只有该Set创建的对象没有初始化该Set的数据来获取Set的值，我们使用@Transactional，即，

//with @Transactional
@Transactional
public Country getCountry(){
   Country country = countryRepository.getCountry();
   //below when we initialize cities using object country so that directly communicate with database and retrieve all cities from database this happens just because of @Transactinal
   Object object = country.getCities().size();   
}

所以基本上@Transactional is Service可以在单个事务中进行多个调用，而无需关闭与端点的连接。

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