MVC 中的单个 DAO 还是多个 DAO？答案

【问题标题】：Single DAO or multiple DAOs in MVC?MVC 中的单个 DAO 还是多个 DAO？
【发布时间】：2013-07-22 20:55:13
【问题描述】：

在一对多的数据库映射场景中，假设一个部门可以有多个员工，那么设计 DAO 层的最佳实践是什么？

我应该使用一个通用 DAO 类来获取/设置部门对象和获取/设置员工对象，还是应该使用两个单独的 DAO 类 DepartmentDAO 和 EmployeeDAO 来分别获取/设置部门对象和员工对象？

【问题讨论】：

【解决方案1】：

我会用一个 dao 来区分 Department 和另一个 Employee 。我认为红旗是：你会怎么称呼合道？

如果您没有立即想到一个清晰直观的名称，则可能是代码异味。如果这个名字没有跳出来，它肯定会让其他看你代码的程序员感到困惑。为什么要把两个截然不同的东西粘在一起？

一些准则：

例如，如果是 Employee 和 Contractor，我可能会更相信将它们组合成一个泛型，但即便如此，我还是有可能将它们分开，除非我有充分的理由不这样做将它们分开。
如果您的项目开始变得庞大，有 15 或 20 个 DAO，您最终可能会决定使用一个 DAO，但这是您可以在下游做出的决定。然后也许你可以创建一个 HumanResources DAO 或类似的东西。这主要是为了防止布线过多。

将部门和员工分开几乎没有什么缺点，而且在代码的清晰度和易于维护方面可能会有一些显着的收益。如果您有充分的理由，将来将它们结合起来并不难。

这是我的看法。

【讨论】：

如果这两个类没有关系，使用两个独立的 DAO 是很明显的。我正在使用 Hibernate 进行 java 类到数据库表的映射，它具有一对多的关系，所以我想知道将两个 DAO 组合在一起是否有任何优势。

【解决方案2】：

实际上，在我看来，您至少需要 3 个不同的 DAO：

事情是 - 单个实体的映射和实体组的映射具有显着差异。因此，它们应该由不同的结构来处理，否则你有违反SRP的风险。

另外，Department 应该与 Employee 实例的集合进行交互，而不是单独与每个实例交互。

【讨论】：