Java EE体系结构-在使用JPA 2之类的ORM时是否仍建议使用DAO？

Question

如果我使用的是JPA2之类的ORM-我的实体已映射到数据库，那么我是否仍应使用DAO？似乎要增加很多开销。

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

1. 一个指定我的域对象的对象（它几乎映射了我的Entity对象）：

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

1. 一种包含指定我的DAO方法的接口

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

1. 其中包含实现我的DAO的会话bean

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

现在，每当我需要执行新的CRUD操作时，都会增加很多额外的负担。

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

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

2. 它将业务逻辑与数据库访问逻辑分开

不涉及实现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层的所有开销的体系结构或实现的体系结构吗？

感谢您的任何建议和/或建议！我真的很想知道有人对此提出了什么建议。

Answer 1

如果我使用的是JPA2之类的ORM-我的实体已映射到数据库，那么我是否仍应使用DAO？似乎要增加很多开销。

它是。显然，Java EE
在使用JPA时不鼓励使用DAO模式（JPA已经提供了域html" target="_blank">存储模式的标准化实现，并且在DAO后面屏蔽它没有太多价值）。我发现DAO
在这种情况下是反干的。

因此，对于 简单的 情况（实际上，大多数情况下），我很乐意跳过DAO，对此我没有任何问题。对于更 复杂的
情况（例如，当使用存储过程，平面文件时），我会使用它。换句话说，这取决于JPA是否杀死了DAO？。另请参阅以下相关问题：

不，您当然不希望将DAO实现为会话Bean：

• 您不想创建与表一样多的（池化）Session Bean（浪费大量资源）
• 您不想在任何地方都链接Session Bean，不要重现过去的错误，这是一种已知的不好的做法，无法很好地扩展。

因此，如果您真的想采用DAO方式并希望注入EM，则可以将DAO实现为Spring Bean（在Java EE 5中）或CDI托管Bean（在Java EE6中）。

您可以在内存中实现DAO，以对服务层进行单元测试。

如果您真的要进行 单元 测试，请模拟DAO/EntityManager，没有区别。而且，如果要进行集成测试，则可以将JPA配置为使用内存数据库。所以最后，我只是不赞成这种说法。

它将业务逻辑与数据库访问逻辑分开

老实说，我认为依靠DAO与实体经理之间没有 太大的 区别，我也看不到DAO如何将事情“更好地”分开。同样，我不赞成这种说法。

根据我的经验，更改底层的持久性解决方案是非常特殊的事情，并且我不会针对不太可能发生的事情引入DAO（YAGNI，KISS）。

这里没有中间立场吗？有人遇到过满足我上面提到的DAO层的某些优点（最重要的是业务逻辑的单元可测试性）但又不涉及实现DAO层的所有开销的体系结构或实现的体系结构吗？

我没有看到太多中间立场，并且强烈暗示说，如果我感觉不到需要，则不使用DAO。正如我所说，EntityManager如果您要真正地对业务逻辑进行单元测试，请模拟一下。它对我有用，我很高兴编写更少的代码。

更多资源

• JPA / EJB3杀死了DAO
• DAO并没有死-但它们要么崩溃，要么消失
• …最后，如果出现以下情况，您应该引入DAO：