DAO模式的最佳实践？

Question

我见过很多代码都使用了service-dao模式，我不知道这个模式的来源。它强制执行前层调用服务，然后将一些服务任务委托给dao。

我想问：

1. DAO层是否完全与数据访问相关的任务？异常封装之类的东西怎么样？
2. 是否可以使用任何其他模式来替换此或更好？
3. 我认为pojo域模型和事务脚本使得即使是简单的问题变得复杂，是否有可能完全消除dao层？

Answer 1

理想情况下，您的DAO层“抽象”了对某些数据存储系统（数据库，文件系统，LDAP目录......）的访问权限。因此，从这个意义上讲，它仅用于与数据访问相关的任务。但是，您还可以使用DAO层访问Web应用程序或应用程序外部的其他组件。这是关键点，它提供了对某些外部组件的访问。

主要思想是没有DAO层的实现细节可以转移到更高层（隔离）。思考这个问题的一个很好的起点是：如果我计划更换我的DAO层提供访问权限的组件（例如数据库），我还需要做什么？例如，您在XML文件中有一些数据，并且您计划将数据迁移到数据库。

假设您有各种与DAO相关的XML相关异常。然后，将XML层迁移到数据库层变得非常困难。但是，如果您已经封装了DAO层的所有实现细节，那么这将变得更加容易。

最后，它是关于代码的可维护性。您对特定层（服务，DAO，...）的实现细节的依赖性越小，代码的可维护性就越好。

Answer 2

这样一层的主要目标是提供持久性后端的抽象。但是，大多数时候，由于持续后端的特殊性，总隐藏是不可能的;一个典型的例子是查询处理。要使用hibernate查询数据库，您将使用JCR，BigTable或其他东西编写某种查询代码（使用HQL，查询API，...）和完全不同的范例。因此，大多数情况下，这种模式失败了。

此外还有DAO / DTO的问题 - 更令人讨厌。然后，您可以继续编写第一个包含数据的类，然后再从第一个数据中复制数据，没有任何附加值只是为了进行图层隔离。

然而，在这个领域已经做了一些工作。对于我已经开始实施谷歌应用程序引擎的微框架，我已经制作了一个little list所谓的dao框架，可以简化这个相当普通的代码。

注意我将来计划通过gaedo服务定义提供完全透明度，但这只是一个希望;-)（我猜你并不是立即感兴趣的。）

Answer 3

根据数据来源，访问数据会有所不同。对存储器的持久存储（例如数据库）的访问因存储类型（关系数据库，面向对象的数据库，平面文件等）和供应商实现而有很大差异。

使用数据访问对象（DAO）来抽象和封装对数据源的所有访问。 DAO管理与数据源的连接以获取和存储数据。

DAO实现了使用数据源所需的访问机制。数据源可以是持久性存储，如RDBMS，外部服务（如B2B交换），存储库（如LDAP数据库），或通过CORBA Internet Inter-ORB协议（IIOP）或低级别套接字访问的业务服务。依赖于DAO的业务组件使用DAO为其客户端公开的更简单的接口。 DAO完全隐藏了客户端的数据源实现细节。由于DAO向客户端公开的接口在基础数据源实现更改时不会更改，因此此模式允许DAO适应不同的存储方案，而不会影响其客户端或业务组件。实质上，DAO充当组件和数据源之间的适配器。