DAO 和服务层（JPA/Hibernate + Spring）

Question

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

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

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

Answer 1

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

Answer 2

有一点是肯定的：如果你在service层使用EntityManager，你不需要dao层（只有一层应该知道实现细节）。除此之外，还有不同的观点：

• 有人说 EntityManager 公开了
  所有需要的 dao 功能，所以他们
  在服务中注入EntityManager
  层。
• 其他人有传统的 dao 层
  由接口支持（因此服务
  层与实现无关
  细节）。

当涉及到关注点分离时，第二种方法更加优雅，并且它也将使从一种持久性技术切换到另一种更容易（您只需使用新技术重新实现 dao 接口），但如果您知道什么都没有会改变，第一个更容易。

我想说，如果您有一个小项目，请在服务层使用 JPA，但在大型项目中请使用专用的 DAO 层。

Answer 3

Adam Bien 的这篇文章可能会有用。

Answer 4

传统上，您将编写定义服务层和数据层之间契约的接口。然后您编写实现，这些就是您的 DAO。

回到你的例子。假设机场和航空公司之间的关系是多对多，并且有一个包含 airport_id 和 Airlines_id 的表，您可能有一个接口；

public interface AirportDAO
{
   public List<Airline> getAirlinesOperatingFrom(Set<Airport> airports);
}

..并且您可以提供一个 Hibernate 实现；

public class HibernateAirportDAO implements AirportDAO
{
   public List<Airline> getAirlinesOperatingFrom(Set<Airport> airports)
   {
      //implementation here using EntityManager.
   }
}

您还可以考虑在航空公司实体上创建一个列表，并使用 @ManyToMany JPA 注释定义关系。这将完全消除这种特定 DAO 方法的必要性。

您可能还想研究用于编写 DAO 工厂的抽象工厂模式。例如;

public abstract class DAOFactory
{
   private static HibernateDAOFactory hdf = new HibernateDAOFactory();

   public abstract AirportDAO getAirlineDAO();

   public static DAOFactory getFactory()
   {
      //return a concrete implementation here, which implementation you
      //return might depend on some application configuration settings.
   }
}

public class HibernateDAOFactory extends DAOFactory
{
   private static EntityManagerFactory emFactory = Persistence.createEntityManagerFactory("myPersistenceUnit");

   public static EntityManager getEM()
   {
      return emFactory.createEntityManager();
   }

   public AirportDAO getAirportDAO()
   {
      return new HibernateAirportDAO();
   }
}

此模式允许您的 HibernateDAOFactory 保存单个 EMF 并为各个 DAO 实例提供 EM。如果您不想走工厂路线，那么 Spring 非常擅长通过依赖注入为您处理 DAO 实例。

编辑：澄清了一些假设。

Answer 5

Dao 是一个数据访问对象。它在数据库上存储/更新/选择实体。实体管理器对象用于此目的（至少在 open jpa 中）。您还可以使用此实体管理器运行查询。它不是 sql，而是 JPQL（Java 持久性查询语言）。

简单的例子：

emf = Persistence.createEntityManagerFactory("localDB");
em = emf.createEntityManager();

Query q = em.createQuery("select u from Users as u where u.username = :username", Users.class);
q.setParameter("username", username);

List<Users> results = q.getResultList();

em.close();
emf.close();