使用DAO模式的优缺点

Question

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

Answer 1

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

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

Answer 2

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

PROS：

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

缺点：

• 它不是最灵活的东西。
• 如果您想延迟加载一些子对象，那么您将不得不将DAO与其他层混合或在尝试检索惰性对象时采取预防措施。
• 如果您手写DAO，那么代码可能会变得乏味和重复。

Answer 3

Benefits of using DAO design pattern

DAO or Data Access Object design pattern is a good example of abstraction and encapsulation object oriented principles. It separates persistence logic is a separate layer called Data access layer which enables application to react safely to change in Persistence mechanism. For example, if you shift from File-based persistence mechanism to Database, your change will be limited to data access layer and won't impact Service layer or domain Objects. Data Access Object or DAO pattern is pretty much standard in Java application being it core Java, web application or enterprise application. Following are couple of more benefits of using DAO pattern in Java application:

1. DAO design pattern also keeps coupling low between different parts of an application. By using DAO design pattern your View Layer is completely independent of DAO layer and only Service layer has the dependency on it which is also abstracted by using DAO interface.

2. DAO design pattern allows JUnit test to run faster as it allows to create Mock and avoid connecting to database to run tests. It improves testing because it's easy to write test with Mock objects, rather than an Integration test with the database. In the case of any issue, while running Unit test, you only need to check code and not database. Also shields with database connectivity and environment issues.

3. Since DAO pattern is based on interface, it also promotes Object oriented design principle "programming for interface than implementation" which results in flexible and quality code.

Answer 4

DAO模式的作用在于它们允许您创建实际存储系统的漂亮抽象层。它们提供了更加面向对象的持久层视图，以及域和实际执行数据访问的代码之间的清晰分离（直接JDBC，持久性框架，ORM甚至JPA）。

如果我不得不引用一个弱点，那么，我会说它是另一层...但我想这是为了不将代码绑定到底层持久性API而付出的代价。

Answer 5

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

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

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

Answer 6

<强> PRO

• DB表的单点定义 - 对象属性映射
• DAO实施到其他存储类型的透明可能性
• 开发所有DAO的界面模式
• 为DAO开发一个或多或少的标准JUnit测试类，以获得更好的测试覆盖率
• 完全控制细节
• 由于过于通用的解决方案而导致性能下降

<强> CON

• 比使用最新框架“性感”
• 开发人员不会发明自己的轮子（可能是PRO： - ））

与大多数开发模式一样，使用DAO需要一些时间来习惯。凭借经验，更强大的代码和开发人员可以了解事情的原因，而不仅仅是看起来如此。最后一点对我来说是最大的优势。

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

Answer 7

您还在考虑哪种替代方案？

似乎很明显，只要从责任明确和重用的角度来看，将持久性的责任放在表示层之外的其他地方通常是好的。我本能地采用三层方法：演示，服务，持久性。承认长期以来一直这样做，以至于我无法通过不这样做的方式获得痛苦的证据。对我来说，似乎“显而易见”的是，拥有一个了解持久性机制的单层必须简化测试，简化维护并且能够很好地分离关注点。

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

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

Answer 8

亲：抽象分离。
Con：样板代码（感谢上帝代码生成器/模板和ORM）。