DAO 已死在 JPA 手上？

最近有人讨论到 Java Persistence API （JPA）是否已经杀死了 Data Access Object （DAO）。JPA 定义了将普通 Java 对象（有些人称之为 POJO）持久化到数据存储的接口。它大致上提供了与 Hibernate 之类相似的对象—关系映射。而 DAO 简单来说，可以总结为：

数据访问对象（DAO）是一种软件组件，它在应用程序与一个或多个数据存储设备（如数据库或文件）之间提供了一种通用的接口。

多数讨论的参与者都选择了各自的立场。其中一方，也是讨论的发起者 Adam Bien 认为：

……用法没法再简单了。只要把 EntityManager 注入到 bean 类……DAO 模式对于一般的数据访问不再有意义，不过某些数据访问还是需要它，比如访问存储过程、纯文件等……

几天之后， Magle 反驳说 DAO 还活得好好的，

上星期有些言论和博客文章谈论 DAO 模式的终结，特别联系到了 EJB 3 及其 EntityManager 的崛起。他们提议在你的面向业务的服务里直接使用 EntityManager，不必再把数据访问逻辑包装到 DAO 里面。我强烈反对这种意见……

Magle 接着解释了他的观点，并特别点出以下几个关键问题：

• 混淆业务逻辑与数据访问逻辑
• 违反了单一职责的原则
• 混淆了业务逻辑与基础设施
• 违反了开放—封闭原则
• 缺乏统一风格的数据访问策略

在对《 JPA/EJB3 Killed the DAO 》的补充帖子里，Adam Bien 进一步阐明了他认为 DAO 不再有必要的理由，

DAO 模式可以看成是“数据服务层”，它封装了特殊的而且常常是专用的数据访问实现。这样一层的主要目的为了让你独立于特定的数据库和 OR 映射实现。但即使是从前，我也从来没试过需要替换数据库，甚至从没试过从 SQL 换到 LDAP。
在有些情况下，例如要封装遗留系统，层次是不可改变的。照我的看法，在 Java EE 5 里面，DAO 可以被大大优化（直到消失掉:-)）。DAO 接口、实现和工厂以及实际的 Session Bean 可以被压缩到一起。当然我们可以争辩依赖于 EJB 3 到底好不好，但为什么不呢？仅仅是因为 @Stateless 标注？

每个帖子都有大量的评论在添柴，比如 WarpedJavaGuy 说：

DAO 还长命着呢。持久化跟数据访问并不完全是一回事。

另一方的 Antonio Goncalves 回复说：

Java EE 的痛处是那些一遍又一遍重复的无聊代码，变成了反模式的设计模式，复杂性等等。在 EJB 里使用 EntitManager 的 CRUD 操作对我来说完全没有问题。对于简单的应用，我会跳过 DAO 模式……

总而言之，一般的公论是取决于应用和需求。 Adam 总结说，

我会说：看情况。取决于你的应用到底有多复杂。

查看英文原文： Has JPA Killed the DAO?