首先，是否应该使用DAO层是自从JPA和EntityManager出现以来一直存在的争论，许多人认为DAO本身就已经存在。答案取决于您正在开发的应用程序类型，但是在大多数情况下，您需要：
- 使用JPA标准或自定义查询 。在这种情况下，您可能不想将业务逻辑与查询创建混在一起。这将导致方法繁多，并违反了单一责任原则。
- 尽可能重用您的JPA代码 。假设您创建一个条件查询，该查询将检索年龄在40到65岁之间并且在公司工作超过10年的员工列表。您可能想在服务层中的其他地方重用这种类型的查询，如果是这种情况，将其包含在服务中将使此任务变得困难。
话虽这么说，如果您的应用程序中只有CRUD操作，并且您不需要重用任何JPA代码，则DAO层可能会显得有些过分，因为它只能充当EntityManager的包装器，听起来不对。
其次，我建议尽可能使用容器管理的事务。如果您使用的是诸如TomEE或JBoss之类的EJB容器，则可以避免使用大量代码来以编程方式创建和管理事务。
如果您使用的是EJB容器，则可以利用声明式事务管理。使用DAO的一个示例是将服务层组件创建为EJB，也将其创建为DAO。
@Statelesspublic class CustomerService { @EJB CustomerDao customerDao; public Long save(Customer customer) { // Business logic here return customerDao.save(customer); }}@Statelesspublic class CustomerDao { @PersistenceContext(unitName = "unit") EntityManager em; public Long save(Customer customer) { em.persist(customer); return customer.getId(); } public Customer readCustomer(Long id) { // Criteria query built here }}在上面的示例中，默认事务配置是必需的，这意味着在调用者组件中不存在事务的情况下，EJB将创建一个新的事务。如果调用者已经创建了事务（CustomerService），则被调用的组件（CustomerDao）将继承该事务。可以使用@TransactionAttribute批注对此进行自定义。
如果您不使用EJB容器，那么我认为您上面的示例可能是等效的。
编辑 ：为简单起见，我在上面使用了无接口EJB，但是对这些接口使用接口以使其更具可测试性是一个很好的做法。
