首先,有可能我提出的问题之前已经有人问过,也有人回答过,但我无法得到搜索结果。我们在服务层上定义了事务性注释,典型的spring hibernate crud通常是
控制器->管理器->Dao->ORM.
我现在遇到了需要在基于客户端站点的域模型之间进行选择的情况。假设客户端A正在使用我的域模型,一切都很好,但是其他客户端站点会给我一个web服务,而不是使用我们的域模型。
我应该替换哪一层。我相信它必须是DAO,它将从web服务中获取数据并将其发送回来,即两个单独编写的DAO层,并根据场景插入。
我现在意识到,当我们将@Transactional
放在服务层时,我们一直在做紧密耦合(如果有这样的事情,或者说没有松散耦合)。那么多的大脑不可能是错的,或者他们是错的(我怀疑)。
所以问题是“应该把"@Transactional
”放在服务层还是DAO的什么地方?“我应该往下替换的是服务层吗?
11年过去了,仍然有意义。如果我回顾一下这个项目,很明显当时我对领域模型的理解是错误的。我认为ORM层是领域模型,我们希望使用ORM和分离的实体,没有任何数据映射,也没有任何DTO。这是当时的趋势。如今,域模型不是ORM,拥有合适的域模型并使用ORM或are服务是解决这个问题的数据源。正如许多人指出的那样,是的,服务是适合它的地方,并且具有适当的领域模型,而不是将JPA (ORM)作为领域模型。
发布于 2015-02-26 15:22:23
理想情况下,服务层(管理器)代表您的业务逻辑,因此应该用@Transactional
对其进行注释。
服务层可以调用不同的DAO来执行DB操作。假设您在一个服务方法中有3个DAO操作。如果您的第一个DAO操作失败,其他两个操作可能仍会通过,您将以不一致的DB状态结束。注释服务层可以将您从这种情况中解救出来。
发布于 2010-10-08 09:12:15
你会希望你的服务是事务性的。如果您的DAO是事务性的,并且您在每个服务中调用不同的DAO,那么您将有多个事务,这不是您想要的。使服务调用成为事务性的,这些方法中的所有DAO调用都将参与该方法的事务。
发布于 2013-09-15 22:50:10
我建议将@Transactional放在服务层方法中,因为我们可以有多个DAO实现。通过使用它,我们可以使我们的服务成为事务性的。refer
最佳实践是使用通用BasicService来提供公共服务。
服务是放置@ transaction的最佳位置,服务层应该包含逻辑上放入事务中的用户交互的详细用例行为。通过这种方式,我们可以保持web应用程序代码和业务逻辑之间的分离。
有很多CRUD应用程序没有任何重要的业务逻辑,对于它们来说,只在控制器和数据访问对象之间传递内容的服务层是没有用的。在这些情况下,我们可以将事务注释放在Dao上。
所以在实践中,你可以把它们放在任何一个地方,这取决于你。
通过在您的服务中使用多个调用,您需要在服务中使用@Transactional。如果您将@ transactions放入服务中,则对服务的不同调用将在不同的事务中执行。
https://stackoverflow.com/questions/3886909
复制相似问题