我正在寻找有关Data Access Object设计模式的反馈，并在您必须跨多个表访问数据时使用它。似乎该模式具有每个表的DAO以及表示单行的数据传输对象（DTO），在处理来自多个表的数据时并不太有用。我正在考虑创建一个复合DAO和相应的DTO来返回结果，比如在两个表上执行连接。通过这种方式，我可以使用SQL来获取所有数据，而不是首先使用一个DAO获取数据，而不是使用第二个DAO获取第二个数据，而不是使用Java将它们组合在一起。
有更好的解决方案吗？不，我现在无法转移到Hibernate或其他ORM工具。这个项目只是直接的JDBC。
答案 0 :(得分：12)
我同意你的做法。我的DAO倾向于在对象级别更多地对齐，而不是从DB Table的角度来看。我可以通过DAO管理多个对象，但它们很可能是密切相关的。没有理由不让SQL访问一个DAO中的两个表。
为了记录，我从词汇和代码中删除了首字母缩略词DTO。
答案 1 :(得分：3)
理想情况下，如何将数据存储在数据库中，然后如何访问它们，应该从域模型中域实体之间关系的性质中得出。也就是说，关系模型应该遵循域模型。例如，如果您有两个实体，例如“用户”和“地址”。
场景＃1 ：地址永远不会被独立访问，它们始终是User的属性。 在这种情况下，Address是一个Value Object，User是一个Entity，并且有关于如何存储这种关系的指南。一种方法是将Address的Address属性与User的属性一起存储在单个表中。在这种情况下，UserDao将处理这两个对象。
场景＃2 ：地址可以与用户相关联，但也可以单独与实体分开。 在这种情况下，需要一种与第一种方法不同的方法。您可能有一个单独的DAO和表格用于地址类型。
我的观点是，更常见的是，这个重要的想法被忽略，域模型应该是应用程序的核心，驱动其他层。
例如，如果您的域模型已正确定义并且您非常了解您拥有的实体类型以及它们之间的关系，那么您的持久性（关系表及其关系，您的DAO等）将演变为你在域模型中所拥有的非常合乎逻辑的结果。
换句话说，如果您花一些时间研究模型，您将能够在确定如何将DAO组织到域模型中的某个位置时跟踪您的问题。如果您可以在域模型中清楚地定义对象的类型以及它们之间关系的性质，它将帮助您解决DAL层中的问题。