服务层或 DAO 应该放在哪里

首先，我可能是在问一些以前被问过和回答过的问题，但是我无法得到一个搜索结果。我们通常在服务层定义事务注释

总监-> 经理-> 刀-> 奥姆。

我现在有一个情况，我需要在基于客户端站点的域模型之间进行选择。 假设客户端 A 正在使用我的域模型，那么其他客户端站点会给我一个 Web 服务，而不是使用我们的域模型。

我应该替换哪一层。我相信它必须是 DAO，它将从 Web 服务获取数据并将其发送回来。也就是说，两个独立编写的 DAO 层，并根据场景插入。

我现在已经意识到，当我们将 @Transactional放在服务层时，我们一直在进行紧密耦合(如果存在这种情况或者说没有松散耦合)。这么多的大脑不可能是错的，或者他们是错的(我对此表示怀疑)。

所以问题是“ @Transactional”应该放在服务层还是 DAO?”它是服务层向下，我应该更换。

11年过去了，依然有意义。如果我回头看看这个项目，我对领域模型的理解显然出了问题。我认为 ORM 层是一个域模型，我们希望使用 ORM 和分离的实体，没有任何数据映射，也没有任何 DTO。那是当时的潮流。现在域模型不再是 ORM，拥有一个合适的域模型和使用 ORM 或 Webservices 是数据源来处理这个问题。像许多人指出的那样，是的，服务是适合它的地方，有适当的域模型，而不把 JPA (ORM)当作域模型。

56709 次浏览
小开

You are going to want your services to be transactional. If your DAOs are transactional, and you call different DAOs in each service, then you would have multiple transactions, which is not what you want. Make the service calls transactional, and all DAO calls inside those methods will participate in the transactions for the method.

小开

i will suggest to put @Transactional in Service layer methods since we can have multiple DAO implementations. by using this we can made our services will be transactional. refer

best practice is to use A generic BasicService to offer common services.

The Service is the best place for putting @Transactional, service layer should hold the detail-level use case behavior for a user interaction that would logically go in a transaction. in this way we can have maintain separation between web application code and business logic.

There are a lot of CRUD applications that don't have any significant business logic, for them having a service layer that just passes stuff through between the controllers and data access objects is not useful. In these cases we can put transaction annotation on Dao.

So in practice you can put them in either place, it's up to you.

By having multiple calls in your service you need @Transactional in service. different calls to service will execute in different transactions if you put @Transactional in service.

小开
最佳答案

Ideally, Service layer (Manager) represents your business logic and hence it should be annotated with @Transactional.

Service layer may call different DAOs to perform DB operations. Lets assume a situation where you have 3 DAO operations in a service method. If your 1st DAO operation failed, other two may be still passed and you will end up with an inconsistent DB state. Annotating Service layer can save you from such situations.

小开

It's of a personal choice based on application types, if application is layerd across many modules and majority of operations are @CRUD based ,then having @transactional annotation at service level makes more sence.. engine type application like schedulers , job servers,@etl report apps, where sessions and user concept does not exists, then propagational transaction at context level is most suitable... we should not end up creating clusterd transactions by putting @transactional every where ending up transactional anti patters...anyways for pragmatic transaction control JTA2 is most suitable answer...again it depends on weather you can use it in a given situations...

小开

You should use @Transactional at service layer, if you want to change the domain model for client B where you have to provide the same data in a different model,you can change the domain model without impacting the DAO layer by providing a different service or by creating a interface and implementing the interface in different model and with the same service populate the model based on the client.This decision is based on the business requirement and the scope of the project.

小开

i have heard in a programming class,that dao layer is responsible for interacting with database, and service is a set of operations might be with dao and therefore database or not and that set of operation is in one transaction, mean is better service be transactional.


提交答案