需要使用Patterns（DAO x Gateway）进行一些澄清 [英] Need some clarification with Patterns (DAO x Gateway)

问题描述

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

我的同事估计，DAO应该返回一个对象（填充的bean）。我认为只有一行返回一个记录集是完全正确的，但是如果你必须返回10行，并创建10个单独的对象，那就认为这是非常有用的。

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

我的问题是：

1. 哪些假设是正确的？


2. 一个
   DAO（即getContact（））的返回类型应该是什么 - 一个记录）


3. 应该使getContacts（）（对于多个记录）甚至是
   DAO，如果是的话，它是returntype？

我们似乎对DAO和Gateway有一些混乱模式。是否应该一起使用？

提前感谢

解决方案

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

我将直接回答问题，这里并扩大以下答案。

1。哪些假设是正确的。
DAO patten关注隐藏实体的实体和查询的细节。返回与持久化机制直接相关的记录集通常不是一个好主意，因为它打破了抽象。通过保持DAO存储不可知，测试要简单得多 - 然后可以使用例如基于存储在集合中的测试数据的简单内存中实现模拟DAO界面。

2。返回类型应该是一个DAO（即getContact（） - 一个记录）
返回类型应该是联系 bean。当您向联系人添加属性时，只有Contact类需要更改 - DAO界面保持不变。

3。 getContacts（）（对于多个记录）甚至是在DAO上，如果是，那么它是returntype？
我将查询方法与其他DAO方法一起放在一起 - 我看不到区别。多个联系人可以作为列表或适当的联系方式返回。 bean。

关于返回对象或只是所需的值是可扩展的设计和性能之一。默认选择应该是返回豆类。大多数ORM映射器甚至JDBC访问层使创建对象相对轻量级（现代JVM可以在10个CPU指令下创建一个新对象），它是迄今为止最好的设计选择，并将轻松发展。

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

bean不需要完全填充。 ORM映射器倾向于懒惰地获取相关的对象和集合，因此您可以获得所需的性能。总结一下，虽然可以混合使用返回bean和非bean结果的方法，但是我将远离非bean结果，除非有一个令人信服的理由这样做。并且意识到可能导致的维护问题。

Me and my colleagues got into this discussion early this morning, and our opinions started to clash a bit, so I decided to get some impartial advice here.

One of my colleagues reckons that the DAO should return an object (populated bean). I think it's completely fine when you're returning a recordset with only one line, but think it's overkill if you have to return 10 lines, and create 10 separate objects.

I on the other see that the difference between DAO and Gateway pattern is that the gateway pattern will allow you to return a recordset to your business class, which will therefore deal with the recordset data and do whatever it needs to do.

My questions here are:

1. Which assumptions are correct?
2. What should the return type be for a DAO (i.e. getContact() - for one record)
3. Should getContacts() (for multiple records) even be on the DAO, if so, what's it's returntype?

We seem to be having some sort of confusion about DAO and Gateway Patterns. Should they be used together?

Thanks in advance

解决方案

The gateway pattern is concerned with providing a single point of access for a system or subsystem. The DAO pattern is a specific type of gateway - it provides the sole means of getting a particular type of data from the data store.

I'll answer the questions directly, here and expand upon the answers below.

1. Which assumptions are correct. The DAO patten is concerned with hiding the details of fetching entities and queries over entities. Returning a recordset that is directly tied to the persistence mechanism is generally not a good idea since it breaks the abstraction. By keeping the DAO storage-agnostic, testing is much simpler - it is then possible to mock the DAO interface using for example a simple in-memory implementation based on test data stored in collections.

2. What should the return type be for a DAO (i.e. getContact() - for one record) The return type should be Contact bean. As you add attributes to the contact, only the Contact class needs to change - the DAO interface stays the same.

3. Should getContacts() (for multiple records) even be on the DAO, if so, what's it's returntype? I put query methods alongside other DAO methods - I don't really see a distinction. Multiple contacts can be returned as a List or appropriate Collection of Contact beans.

The debate about returning objects or just the needed values is one of extensible design and performance. The default choice should be to return Beans. Most ORM mappers and even JDBC access layers make creating objects relatively lightweight (modern JVMs can create a new object in under 10 CPU instructions), and it is by far the best design choice, and will evolve easily.

Returning non-object results, such as a list of CustomerIDs is a possibility, but should be taken when there is clear evidence that it is necessary. Performance is usually the motivating factor, and so the design should be backed up with profiling evidence. Otherwise this is likely to be sacrificing good design in favor of premature optimization. Extending a design that returns non-object data can be difficult - say you want now to return the customer ID and the last order date. If you are returning data as rows and primitive types, then the shape of the return type is going to change, typically requiring the methods on the DAO interface and implementation to change, and all clients that use them. With a bean, related data can be fetched without changing the shape of the data - assuming the related data is available starting from the bean already being returned.

The beans do not need to be fully populated. ORM mappers tend to lazily fetch related objects and collections, so you take the performance hit for what just what you retrieve.

To sum up, while it is possible to have a mix of methods returning bean and non-bean results, I would steer away from the non-bean results unless there is a compelling reason to do so. And do so with awareness of the maintainance issues this may cause.

这篇关于需要使用Patterns（DAO x Gateway）进行一些澄清的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！