我和我的同事今天早上进入了这个讨论，我们的意见开始发生冲突，所以我决定在这里得到一些公正的建议。
我的一位同事认为DAO应该返回一个对象（填充的bean）。我认为只返回一行只有一行的记录集时会完全没问题，但如果你必须返回10行并创建10个单独的对象，那就认为这样做太过分了。
我在另一方面看到DAO和Gateway模式之间的区别在于网关模式允许您将记录集返回到业务类，因此它将处理记录集数据并执行它需要做的任何事情。 / p>
我的问题是：
我们似乎对DAO和网关模式存在某种混淆。它们应该一起使用吗？
提前致谢
答案 0 :(得分：19)
网关模式涉及为系统或子系统提供单点访问。 DAO模式是一种特定类型的网关 - 它提供了从数据存储中获取特定类型数据的唯一方法。
我将直接回答这些问题，并在下面展开答案。
<强> 1。哪些假设是正确的。 DAO模式涉及隐藏实体上获取实体和查询的细节。返回与持久性机制直接相关的记录集通常不是一个好主意，因为它打破了抽象。通过保持DAO存储不可知，测试更加简单 - 然后可以使用例如基于存储在集合中的测试数据的简单内存实现来模拟DAO接口。
<强> 2。 DAO的返回类型应该是什么（即getContact（） - 对于一条记录）
返回类型应为Contact bean。在向联系人添加属性时，只需要更改Contact类 - DAO接口保持不变。
第3。 getContacts（）（对于多个记录）是否应该在DAO上，如果是这样，它的返回类型是什么？
我把查询方法和其他DAO方法放在一起 - 我真的没有看到区别。多个联系人可以作为列表或适当的Contact bean集合返回。
关于返回对象或仅需要的值的争论是可扩展的设计和性能之一。默认选择应该是返回Beans。大多数ORM映射器甚至JDBC访问层使创建对象相对轻量级（现代JVM可以在10个CPU指令中创建新对象），它是迄今为止最好的设计选择，并且将很容易发展。
返回非对象结果（例如CustomerID列表）是可能的，但应在有明确证据证明有必要时采取。性能通常是激励因素，因此应该使用分析证据来支持设计。否则，这可能会牺牲良好的设计，有利于过早优化。扩展返回非对象数据的设计可能很困难 - 比如说您现在想要返回客户ID和最后订单日期。如果要将数据作为行和基元类型返回，则返回类型的形状将发生变化，通常需要更改DAO接口和实现上的方法以及使用它们的所有客户端。使用bean，可以在不改变数据形状的情况下获取相关数据 - 假设相关数据从已经返回的bean开始可用。
bean不需要完全填充。 ORM mappers倾向于懒惰地获取相关的对象和集合，因此您可以将性能提升到您检索的内容。
总而言之，虽然可以混合使用返回bean和非bean结果的方法，但除非有令人信服的理由，否则我会避开非bean结果。并且在了解可能导致的维护问题的情况下这样做。
答案 1 :(得分：2)
这是一种设计模式，最重要的是要保持一致。在我看来，DAO应该返回业务对象而不返回记录集，除非有非常好的商业理由避免这样做。如果函数可能返回多个对象，则它应返回一个对象集合。 更好的是，使用像JPA或hibernate这样的框架，这样你就可以让框架处理持久性。