DAO和服务层（JPA /休眠+春季）

Question

我正在设计一个基于JPA / Hibernate，Spring和Wicket的新应用。我对DAO和Service层之间的区别还不清楚。根据维基百科，DAO是

一个为某种类型的数据库或持久性机制提供抽象接口的对象，提供某些特定的操作而不公开数据库的详细信息。

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

Answer 1

DAO应该提供对单个 相关 数据源的访问，并且根据业务模型的复杂程度，DAO
将返回完整的业务对象或简单的数据对象。无论哪种方式，DAO方法都应在某种程度上紧密反映数据库。

服务可以提供更高级别的界面，不仅可以处理您的业务对象，而且可以首先访问它们。如果从服务获得业务对象，则可以从不同的数据库（和不同的DAO）创建该对象，并可以使用HTTP请求中的信息修饰该对象。它可能具有某些业务逻辑，可以将多个数据对象转换为单个健壮的业务对象。

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

具体问题的答案：

我想知道DAO是否可以包含与数据访问无关的方法，但是使用查询执行起来会更容易吗？

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

在我看来，它更像是一种服务层方法，但是我不确定在服务层中使用JPA EntityManager是否是良好做法的示例？

如果要在服务中使用实体管理器，那么可以将实体管理器视为DAO，因为这就是事实。如果您需要删除一些多余的查询构建，请不要在服务类中删除，将其提取到利用实体管理器的类中，然后将其制成DAO。如果您的用例非常简单，则可以完全跳过服务层，而在控制器中使用实体管理器或DAO，因为您要做的所有服务都是将对getAirplaneById()DAO的调用传递给其他用户findAirplaneById()

更新-
为了澄清下面的讨论，在大多数情况下（由于注释中突出显示的各种原因）还存在DAO层的情况下，在服务中使用实体管理器可能不是最佳决定。但我认为，鉴于以下情况，这将是完全合理的：

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...
   }
}