DAO 和服务层(JPA/Hibernate + Spring) [英] DAO and Service layers (JPA/Hibernate + Spring)

问题描述

我正在设计一个基于 JPA/Hibernate、Spring 和 Wicket 的新应用.DAO 和服务层之间的区别对我来说并不是很清楚.根据维基百科，DAO是

I'm designing a new app based on JPA/Hibernate, Spring and Wicket. The distinction between the DAO and Service layers isn't that clear to me though. According to Wikipedia, DAO is

一个提供抽象的对象某种类型的数据库的接口或持久化机制，提供一些具体操作不暴露数据库的详细信息.

an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database.

我想知道 DAO 是否可以包含与数据访问无关的方法，但使用查询执行起来更容易吗?例如获取在一组特定机场运营的所有航空公司的列表"?在我看来，它更像是一种服务层方法，但我不确定在服务层中使用 JPA EntityManager 是否是一个良好实践的例子?

I was wondering whether a DAO could contain methods that don't really have to do much with data access, but are way easier executed using a query? For example "get a list of all airlines that operate on a certain set of airports"? It sounds to me to be more of a service-layer method, but I'm not sure if using JPA EntityManager in the service layer is an example of good practice?

推荐答案

DAO 应该提供对单个相关数据源的访问，并且根据您的业务模型的复杂程度，将返回完整的成熟的业务对象，或简单的数据对象.无论哪种方式，DAO 方法都应该更接近地反映数据库.

A DAO should provide access to a single related source of data and, depending on how complicated your business model, will return either full fledged Business objects, or simple Data objects. Either way, the DAO methods should reflect the database somewhat closely.

服务可以提供更高级别的接口，不仅可以处理您的业务对象，还可以首先访问它们.如果我从服务中获取业务对象，则该对象可能是从不同的数据库(和不同的 DAO)创建的，它可以用 HTTP 请求中的信息进行修饰.它可能具有特定的业务逻辑，可以将多个数据对象转换为单个、健壮的业务对象.

A Service can provide a higher level interface to not only process your business objects, but to get access to them in the first place. If I get a business object from a Service, that object may be created from different databases (and different DAO's), it could be decorated with information made from an HTTP request. It may have certain business logic that converts several data objects into a single, robust, business object.

我通常会创建一个 DAO，认为它将被任何将要使用该数据库或一组业务相关数据的人使用，它实际上是数据库中除触发器、函数和存储过程之外的最低级别代码.

I generally create a DAO thinking that it will be used by anyone who is going to use that database, or set of business related data, it is literally the lowest level code besides triggers, functions and stored procedures within the database.

对具体问题的回答:

我想知道 DAO 是否可以包含实际上没有的方法对数据访问做很多事情，但是使用查询更容易执行?

I was wondering whether a DAO could contain methods that don't really have to do much with data access, but are way easier executed using a query?

在大多数情况下，不，您希望在您的服务层中使用更复杂的业务逻辑，即来自单独查询的数据的组装.但是，如果您关心处理速度，服务层可能会将操作委托给 DAO，即使它破坏了模型的美感，这与 C++ 程序员可能编写汇编代码以加快某些操作的方式非常相似.

for most cases no, you would want your more complicated business logic in your service layer, the assembly of data from separate queries. However, if you're concerned about processing speed, a service layer may delegate an action to a DAO even though it breaks the beauty of the model, in much the same way that a C++ programmer may write assembler code to speed up certain actions.

在我看来更像是一个服务层方法，但我不确定如果在服务层是一个很好的例子练习?

It sounds to me to be more of a service-layer method, but I'm not sure if using JPA EntityManager in the service layer is an example of good practice?

如果您打算在您的服务中使用实体管理器，那么将实体管理器视为您的 DAO，因为它正是如此.如果您需要删除一些冗余的查询构建，请不要在您的服务类中这样做，将其提取到使用实体管理器的类中并将其设为您的 DAO.如果您的用例真的很简单，您可以完全跳过服务层并在控制器中使用实体管理器或 DAO，因为您的所有服务要做的就是将对 getAirplaneById() 的调用传递给DAO 的 findAirplaneById()

If you're going to use your entity manager in your service, then think of the entity manager as your DAO, because that's exactly what it is. If you need to remove some redundant query building, don't do so in your service class, extract it into a class that utilized the entity manager and make that your DAO. If your use case is really simple, you could skip the service layer entirely and use your entity manager, or DAO in controllers because all your service is going to do is pass off calls to getAirplaneById() to the DAO's findAirplaneById()

更新 - 为了澄清下面的讨论，在大多数情况下，由于评论中突出显示的各种原因还有一个 DAO 层，在服务中使用实体管理器可能不是最佳决策.但在我看来，这是完全合理的:

UPDATE - To clarify with regard to the discussion below, using an entity manager in a service is likely not the best decision in most situations where there is also a DAO layer for various reasons highlighted in the comments. But in my opinion it would be perfectly reasonable given:

1. 服务需要与不同的数据集进行交互
2. 至少一组数据已经有一个 DAO
3. 服务类驻留在需要一些持久性的模块中，该持久性足够简单，不能保证它是自己的 DAO

示例.

//some system that contains all our customers information
class PersonDao {
   findPersonBySSN( long ssn )
}

//some other system where we store pets
class PetDao {
   findPetsByAreaCode()
   findCatByFullName()
}

//some web portal your building has this service
class OurPortalPetLostAndFoundService {

   notifyOfLocalLostPets( Person p ) {
      Location l = ourPortalEntityManager.findSingle( PortalUser.class, p.getSSN() )
        .getOptions().getLocation();
      ... use other DAO's to get contact information and pets...
   }
}

这篇关于DAO 和服务层(JPA/Hibernate + Spring)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！