需要对模式进行一些澄清(DAO X网关)

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

我将在这里直接回答这些问题,并展开下面的回答。

1。哪些假设是正确的。 DAO模式涉及隐藏获取实体的细节和对实体的查询。返回直接绑定到持久性机制的记录集通常不是一个好主意,因为它破坏了抽象。通过保持DAO存储的不可知性,测试就变得简单多了——然后可以模拟DAO接口,例如使用基于存储在集合中的测试数据的简单内存实现。

2。DAO的返回类型应该是什么(即getContact()—对于一个记录) 返回类型应为 Contact 豆类。当您向联系人添加属性时,只需要更改联系人类—DAO接口保持不变。

三。getContacts()(对于多个记录)是否应该在DAO上,如果是,它是什么返回类型? 我把查询方法和其他DAO方法放在一起——我看不出有什么区别。可以将多个联系人作为列表或适当的集合返回 接触 豆。

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

返回非对象结果(如客户列表)是一种可能性,但当有明确证据表明有必要时,应采取这种做法。性能通常是激励因素,因此设计应该有分析证据支持。否则,这可能会牺牲良好的设计,而有利于过早的优化。扩展一个返回非对象数据的设计可能很困难——假设您现在想要返回客户ID和最后一个订单日期。如果要以行和基元类型返回数据,则返回类型的形状将发生更改,通常需要更改DAO接口和实现上的方法以及使用这些方法的所有客户机。使用bean,可以在不改变数据形状的情况下获取相关数据——假设相关数据从已经返回的bean开始就可用。

这些bean不需要完全填充。ORM映射器往往会懒散地获取相关的对象和集合,因此您会因为检索到的内容而受到性能影响。

综上所述,虽然返回bean和非bean结果的方法可以混合使用,但是我会避开非bean结果,除非有令人信服的理由这样做。并且要意识到这可能导致的维护问题。

这是一个设计模式,最重要的是保持一致。在我看来,DAOS应该返回业务对象,而不是返回记录集,除非有非常好的业务原因避免这样做。如果一个函数可能返回多个对象,它应该返回一个对象集合。 更好的是,使用类似JPA或Hibernate的框架,这样您就可以让框架负责持久性。