使用 DAO 模式的优缺点 [关闭]答案

【问题标题】：Pros and cons of the use of the DAO pattern [closed]使用 DAO 模式的优缺点 [关闭]
【发布时间】：2010-12-17 10:07:02
【问题描述】：

正如我在标题中提到的，我很想知道您（作为经验丰富的开发人员）对使用 DAO 模式的看法，特别是在 Web 应用程序中。您发现了哪些优点以及您不喜欢使用它的哪些后果？

【问题讨论】：

除非它是一个 hello world 应用程序，否则肯定不会有任何模式：P
主观题必须是wiki，至少
我对以下答案中反映的暗示感到惊讶，即 DAO 模式以手工制作的数据访问实现为前提。这当然不是我的理解。在我看来，无论是使用 ORM 还是直接 JDBC，DAO 模式都提供了关注点分离。
@Malcolm：嘿，ODBC 等怎么样？无论如何我同意你的观点:)

标签： java sql web-applications dao architectural-patterns

【解决方案1】：

我看到的 DAO 的问题是它们通常总是处理完整的对象。这会产生完全不需要的开销，而简单查询则不存在这些开销。例如，如果要根据数据库引用数据创建下拉列表，DAO 用户可能会简单地说：“给我获取此表的对象集合，其中 y 按 z 排序”。然后，该数据在下拉列表中使用，但通常仅用于键/值组合，忽略检索和映射的对象中的所有其他内容（创建的数据、最后更新它的用户、它是否处于活动状态等） .即使这种按摩发生在 DAO 调用附近，并且对象在检索时没有被存储（通常情况并非如此，不幸的是，对象通常被包装在 ac:forEach (JSP) 中并迭代以产生下拉)，它仍然会产生不必要的数据库和网络开销，更不用说临时增加内存来保存这些对象了。

现在，这并不是说不能将 DAO 设计为检索参考数据的 Map - 它当然可以。但通常它们用于完整的对象映射，这并不是一直需要的。保存时这是一种优势，但在检索数据时，IMO 是一种劣势——当然，你得到了所有的数据——但通常你并不需要所有的数据，它只会浪费内存、带宽和时间。

【讨论】：

这就是我最初提出问题的原因，感谢您的回答。而且我还有另一个问题：在值对象中使用静态工厂方法而不是构造函数怎么样，并且为此专门的查询尝试在对象中构建一种“查询包装器”。你认为也许是一个不错的选择吗？我imho认为它可以带来性能优化，但我不确定，你怎么看？
我觉得可以带来性能优化，但是需要统一处理。例如，工厂方法如何访问数据存储？您会将这些信息传递给构造函数，使用保存信息的静态类，还是什么？工厂模式在这里可能会更好，因为您可以使用多种方法在界面上创建对象，您可以使用您在后台配置的任何内容。
好的，我会通过你的想法，看看

【解决方案2】：

注意：您可能会发现其他缺点，但这里是我的经验的快速列表

优点：

检索对象的常用调用。
一旦你设置了通用的创建/读取/更新/删除流程，就可以为其他 DAO 重复通用布局。
它还整合了代码的持久性特定部分可以去哪里。将业务逻辑与代码的其他组件分开。

缺点：

这不是有史以来最灵活的事情。
如果您想延迟加载某些子对象，那么您将不得不将 DAO 与其他层混合，或者在尝试检索延迟对象时采取预防措施。
如果您手写 DAO，那么代码可能会变得乏味和重复。

【讨论】：

handwriting... pro：从现有数据库模式自动生成源代码非常容易（或至少是直接的）。

【解决方案3】：

使用 DAO 设计模式的好处

DAO 或数据访问对象设计模式是抽象和封装面向对象原则的一个很好的例子。它分离持久性逻辑是一个单独的层，称为数据访问层，它使应用程序能够安全地对持久性机制的变化做出反应。例如，如果您从基于文件的持久性机制转移到数据库，您的更改将仅限于数据访问层，不会影响服务层或域对象。数据访问对象或 DAO 模式在 Java 应用程序中非常标准，无论是核心 Java、Web 应用程序还是企业应用程序。以下是在 Java 应用程序中使用 DAO 模式的更多好处：

DAO 设计模式还保持应用程序不同部分之间的低耦合。通过使用 DAO 设计模式，您的视图层完全独立于 DAO 层，只有服务层对其具有依赖关系，这也是通过使用 DAO 接口抽象出来的。
DAO 设计模式允许 JUnit 测试运行得更快，因为它允许创建 Mock 并避免连接到数据库来运行测试。它改进了测试，因为使用 Mock 对象编写测试很容易，而不是使用数据库进行集成测试。在任何问题的情况下，在运行单元测试时，您只需要检查代码而不是数据库。还可以屏蔽数据库连接和环境问题。
由于DAO模式是基于接口的，它还提倡面向对象的设计原则“为接口编程而不是实现”，从而产生灵活和高质量的代码。

【讨论】：

那么DAO和Repository模式有什么区别呢？

【解决方案4】：

DAO 模式的强大之处在于，它们允许您为实际存储系统创建一个很好的抽象层。它们提供了一个更加面向对象的持久层视图，并在域和实际执行数据访问的代码（直接 JDBC、持久性框架、ORM 甚至 JPA）之间进行了清晰的分离。

如果我不得不举一个弱点，好吧，我会说它是另一层......但我想这是不将代码绑定到底层持久性 API 所付出的代价。

【讨论】：

数据访问层与 DAO 有什么关系？我们在 Rails 中使用胖模型，所有数据访问也是通过模型完成的。尽管如此，这组模型构成了 DAL，而不是 DAO。这是 Rails（和其他）网络应用程序中非常常见的模式。
好吧，我不确定我是否明白你的问题，但对我来说，数据访问层 (DAL) 可能由多个 DAO 组成。这是 Java 中非常常见的模式，它没有 Rails 提供的所有功能（例如活动记录）。

【解决方案5】：

我们已经看到了将 DAO 模式引入我们的实现的一些真正好处。这主要是由于数据库接口和实现之间的明确分离。我们观察到以下好处：

实际数据库访问实现的抽象将数据访问策略与用户业务逻辑分开。这使我们能够为初始项目阶段选择短期（Spring JDBC 模板）实施策略，并可以选择在以后迁移到 IBATIS 或 Hibernate。（我们目前无法做出选择。）
分离带来了显着的可测试性优势，因为可以在单元测试中模拟整个数据访问实现。（这可能是最大的好处）
将其与 Spring 相结合，我们可以将任何 DB 实现注入到我们选择的系统中（尽管这可能更多地说明了 DI 而不是 DAO 模式）。

我们遇到的一个问题，这可能是由于我们缺乏清晰的设计，是“倾向于”重用从数据库发布的数据值对象作为在后续抽象层之间的传输对象。建筑学。经过一番痛苦之后，我们的解决方案是每层都有一个值对象（即不在后续架构层中重用数据库值对象）。

【讨论】：

【解决方案6】：

您正在考虑什么替代方案？

似乎很明显，将持久性责任放在表示层以外的地方通常是好的，这只是从责任清晰和重用的论点来看。我本能地采用三层方法：演示、服务、持久性。承认我已经这样做了很长时间，以至于我无法举出不这样做所遭受的痛苦的证据。在我看来，拥有一个理解持久性机制的单层必须简化测试、简化维护并提供良好的关注点分离，这似乎是“显而易见的”。

这就留下了如何做持久层的问题。我的默认假设是使用 JPA（或类似框架）。我确实认为这是 DAO 的一个复杂示例。

所以我看到了 DAO 的两个成本。首先你需要投资你的程序结构，它的设计。对于琐碎的情况，这可能感觉有点矫枉过正。其次，如果您使用为您实现 DAO 的框架，则存在学习曲线。与直接编写 JDBC 代码相比，这是另一项投资。

【讨论】：

当然，我说的是手工编码的 DAO（带有 VO 和所有这些东西）vrs Hibernate 或类似的东西。我不确定这一点，但我在尝试使用 Hibernate 或类似的东西并尝试定义多对多关系时遇到了一些问题......所以看到其他选项总是很高兴。

【解决方案7】：

专业：抽象分离。
缺点：样板代码（感谢上帝提供代码生成器/模板和 ORM）。

【讨论】：

【解决方案8】：

专业版

DB 表的单点定义 - 对象属性映射
DAO 实现对其他存储类型的透明可能性
开发一个所有 DAO 都遵循的接口模式
为 DAO 开发或多或少标准的 JUnit 测试类可提高测试覆盖率
完全控制细节
不会因为过于通用的解决方案而造成性能损失

骗局

没有使用最新框架那么“性感”
开发人员不能自己发明轮子（可能是专业人士 :-)）

与大多数开发模式一样，使用 DAO 需要一些时间来适应。经验带来的好处是更健壮的代码和知道事情为什么会起作用的开发人员，而不仅仅是看起来如此。最后一点对我来说是最大的优势。

注意，根据您的情况，使用持久性框架可能是编写您自己的 DAO 的一个很好的替代方案。

【讨论】：

> 开发人员不能发明自己的轮子（可能是专业人士:-)）它绝对是专业人士。那里已经有很多轮子了。
@Rui：哦，好吧，愚蠢的我试图添加一点幽默。当然它是专业的（错过了:-)？），一些开发人员的声明版本是 DAO 模式不够“灵活”并将其呈现为 CON。
我也从我的一个朋友那里听说过，他是一位数据库“专家”……而且我并不清楚这种不同的看待方式。感谢您的回答！
为善用性感这个词而投票！因为答案是有道理的。