Java EE 架构 - 使用 JPA 2 之类的 ORM 时，是否仍然推荐使用 DAO？答案

【问题标题】：Java EE Architecture - Are DAO's still recommended when using an ORM like JPA 2?Java EE 架构 - 使用 JPA 2 之类的 ORM 时，是否仍然推荐使用 DAO？
【发布时间】：2011-04-18 15:06:52
【问题描述】：

如果我使用 JPA2 之类的 ORM - 我的实体映射到我的数据库，我还应该使用 DAO 吗？这似乎需要更多的开销。

例如，我需要维护三个额外的包：

一个指定我的域对象（它几乎映射我的实体对象）：

public class Employee {
    private String firstName;
    private String lastName;
    ...
    // Getters and setters
}

一个包含指定我的 DAO 方法的接口

public interface EmployeeDAO {
    public void addEmployee(Employee employee);
    public Employee getEmployeeById(long id);
    ...
}

一个包含实现我的 DAO 的会话 bean

public EmployeeJpaDAO implements EmployeeDAO {
    interface method implementations here
    ....
    private method that transform my Employee entity into my Employee domain object
}

现在每次我需要执行新的 CRUD 操作时都会添加很多额外的包袱。

但是，我从 DAO 中看到的好处是：

您可以在内存中实现 DAO，以便对服务层进行单元测试。这意味着您无需访问数据库即可测试业务逻辑，并且您可以放心，您的对象将始终包含相同的属性值
将业务逻辑与数据库访问逻辑分离

不涉及实现 DAO 的选项是仅在服务层中使用实体对象和 EntityManager：

@Stateless
public class EmployeeEjb {
    @PersistenceContext(unitName = "employee")
    private EntityManager manager;

    public Employee getEmployeeById(long id) {
        return manager.createNamedQuery(Employee.GetEmployeeById).getResultList();
    }
    ...
}

这里没有中间立场吗？有没有人遇到过一个架构或实现了一个架构，它满足了我上面提到的 DAO 层的一些好处（最重要的是业务逻辑的单元可测试性），但不涉及实现 DAO 层所涉及的所有开销？

感谢任何建议和/或建议！我真的很想看看有些人对此有何看法。

【问题讨论】：

标签： java jakarta-ee dao jpa-2.0 architecture

【解决方案1】：

如果我使用 JPA2 之类的 ORM - 我的实体映射到我的数据库，我还应该使用 DAO 吗？这似乎需要更多的开销。

是的。很明显，Java EE 不鼓励在使用 JPA 时使用 DAO 模式（JPA 已经提供了 Domain Store 模式的标准化实现，并且在 DAO 后面屏蔽它没有太大价值）。在这种情况下，我发现 DAO 是反DRY。

所以对于简单案例（实际上，大多数情况），我很乐意跳过 DAO，我对此没有任何问题。对于更复杂的情况（例如使用存储过程、平面文件时），我会使用它。换句话说，这取决于Has JPA Killed the DAO? 中的总结。另请参阅以下相关问题：

相关问题

更多资源