设计 DAL 和 BLL - 相关表的单个/多个数据存储库

Posted 2023-02-24

【中文标题】设计 DAL 和 BLL - 相关表的单个/多个数据存储库

【英文标题】：Designing DAL and BLL - Single/Multiple Data Repository for the Related Tables

【发布时间】：2017-07-17 15:50:09

【问题描述】：

在设计新的多层应用程序时，我在为 DAL 和 BLL 层设计做出决定时遇到了困难。

假设我将员工信息分布在多个表中，这些表与主表具有 1-1 和 1-Many 关系。下面列出的很少：

员工（主表）， Employee_Contact_Detail, Employee_Education, Employee_Skill, 员工体验

在 DAL 级别，我有一个通用数据存储库，为每个表提供通用功能，例如 GetAll、GetSingle、Add、Edit、Delete。

现在，我是否应该设计从我的“通用数据存储库”派生的“员工数据存储库”，并将上面列出的所有相关表的函数添加到单个类中，例如 GetEmployeePersonalDetail、GetEmployeeContactDetail、GetEmployeeEducation、AddEmployeePersonalDetail、EditEmployeePersonalDetail 等。以这种方式我会从“通用数据存储库”中获得非常少的好处。另一种方法是我为每个表创建（并从通用存储库派生）一个单独的数据存储库，然后在业务逻辑层为“员工”创建一个类。

编辑

如果我在 DAL 级别选择“每个表的单独数据存储库”选项，而不是“员工”的“单个业务逻辑类”，如果我创建单独的业务逻辑类，对应于每个数据存储库，考虑到这种情况会是不雅的方法吗？

非常感谢您的指导。

【参考方案1】：

正如在对您的问题的评论中提到的，这是我的意见。

问题：

如果您已经有基础存储库，为什么要为每个表创建特定的存储库？同样，在 BLL 中，您正在为每个存储库创建单独的 Service 类（您提到的“业务逻辑类”）。这都是重复工作，难以管理和理解。

建议：

你没有提到你正在使用什么 ORM（如果有的话）；所以我假设您的 ORM 提供了实现以下架构的必要功能。 我建议您在通用存储库中关闭您的 DAL。不要为特定表编写 DAL 类。您的所有服务类都将使用通用 DAL 来实现基本的 CRUD 功能。所有扩展功能都应该在 Service 类本身中实现。

关于服务类，不是为每个存储库/表创建一个类，而是再次重复工作。更好地将相关的多个表（参考上述段落的存储库问题）分组到一个服务中。

例如，您创建了为所有表提供基本功能的通用 DAL。您创建 EmployeeService 涵盖所有与员工相关的表。您创建的 AccountService 涵盖了所有与会计相关的表。同样，LogService 用于所有与日志记录相关的活动。当您将所有相关成员都放在一个类中时，这使得与服务交互变得容易。这也减少了重复工作。

参考我的this 和this 问题及其接受的答案。

我希望这能解释您的担忧。

编辑 1

正如您在评论中提到的，您是我们的 EF。它支持实现我建议的必要功能。

在 BLL 而不是 DAL 中实现扩展功能将重叠层角色

是的；确实如此。另一面也一样。当您为每个表编写 DAL 时，实际上是在泄漏 DAL 中的业务逻辑。如果业务逻辑发生任何变化，您需要修改没有意义的 DAL。 在我的建议中，即使层是重叠的，关注点仍然是分开的。 DAL 只处理 CRUD。 BLL 处理所有逻辑，包括数据库逻辑。

您是否在任何项目中使用过相同的策略？

是的。在之前的一些项目中，我为每个表创建了单独的 DAL，而不是通用 DAL。这导致了巨大的重复工作。尽管项目相对较小，但维护开销更大。几个月前，我从一个相对较大的项目开始，在那里我实现了我上面的建议。我们现在可以看到给我们带来的宽慰。

【讨论】：

感谢您的建议，这似乎很有用；更少的编码和最小的复杂性。我唯一担心的是，在 BLL 而不是 DAL 中实现扩展功能会重叠层角色，我不确定随着项目的发展，我是否能够继续使用相同的策略而不会出现任何并发症。您是否在任何项目中使用过相同的策略？顺便说一句，我正在使用 EF6。

非常感谢您分享您的经验，让我更有信心。