design-patterns - 需要对模式进行一些说明(DAO x 网关)

Question

我和我的同事今天一大早就开始讨论这个问题，我们的意见开始有点冲突，所以我决定在这里得到一些公正的建议。

我的一位同事认为 DAO 应该返回一个对象(填充的 bean)。我认为当您返回只有一行的记录集时完全可以，但是如果您必须返回 10 行并创建 10 个单独的对象，则认为这太过分了。

另一方面，我看到 DAO 和网关模式之间的区别在于网关模式将允许您将记录集返回到您的业务类，因此它将处理记录集数据并执行它需要做的任何事情。

我的问题是:

哪些假设是正确的？

返回类型应该是什么
DAO(即 getContact() - 一条记录)

getContacts() (用于多条记录)是否应该在
DAO，如果是，它的返回类型是什么？

我们似乎对 DAO 和网关模式有些困惑。它们应该一起使用吗？

提前致谢

Answer 1

网关模式关注为系统或子系统提供单点访问。 DAO 模式是一种特定类型的网关——它提供了从数据存储中获取特定类型数据的唯一方法。

我将在此处直接回答问题，并扩展以下答案。

1. 哪些假设是正确的。
DAO 模式关注隐藏获取实体和查询实体的细节。返回与持久性机制直接相关的记录集通常不是一个好主意，因为它破坏了抽象。通过保持 DAO 存储不可知，测试变得更加简单 - 然后可以使用例如基于存储在集合中的测试数据的简单内存实现来模拟 DAO 接口(interface)。

2. DAO 的返回类型应该是什么(即 getContact() - 一条记录)
返回类型应为 Contact bean 。当您向联系人添加属性时，只需更改 Contact 类 - DAO 接口(interface)保持不变。

3. getContacts()(用于多条记录)是否应该在 DAO 上，如果是，它的返回类型是什么？
我将查询方法与其他 DAO 方法放在一起——我看不出有什么区别。多个联系人可以作为 Contact 的列表或适当集合返回 bean 。

关于返回对象或只是需要的值的争论是可扩展设计和性能之一。默认选择应该是返回 Beans。大多数 ORM 映射器甚至 JDBC 访问层都使得创建对象相对轻量级(现代 JVM 可以在 10 条 CPU 指令以下创建一个新对象)，它是迄今为止最好的设计选择，并且会很容易发展。

返回非对象结果(例如 CustomerID 列表)是可能的，但应在有明确证据表明有必要时采用。性能通常是激励因素，因此设计应该有分析证据支持。否则，这可能会牺牲良好的设计以支持过早的优化。扩展返回非对象数据的设计可能很困难 - 假设您现在想要返回客户 ID 和最后订购日期。如果您将数据作为行和原始类型返回，那么返回类型的形状将会改变，通常需要改变 DAO 接口(interface)和实现上的方法，以及所有使用它们的客户端。使用 bean，可以在不改变数据形状的情况下获取相关数据——假设相关数据从已经返回的 bean 开始可用。

bean 不需要完全填充。 ORM 映射器倾向于懒惰地获取相关的对象和集合，因此您会因检索到的内容而受到性能影响。

总而言之，虽然可以混合使用返回 bean 和非 bean 结果的方法，但除非有令人信服的理由，否则我会避开非 bean 结果。并在意识到这可能导致的维护问题的情况下这样做。