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

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

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

它是。显然，Java EE
在使用JPA时不鼓励使用DAO模式（JPA已经提供了域存储模式的标准化实现，并且在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：