设计 DAL 和 BLL - Single/Multiple 相关表的数据存储库
Designing DAL and BLL - Single/Multiple Data Repository for the Related Tables
在设计新的多层应用程序时，我在为我的 DAL 和 BLL 层设计做出决定时面临困难。
假设我的员工信息分布在多个 table 中，与主人 table 具有 1-1 和 1-Many 关系。下面列出了一些：
员工（硕士Table），
Employee_Contact_Detail,
Employee_Education,
Employee_Skill,
Employee_Experience
在 DAL 级别，我有一个通用数据存储库，为每个 table 提供通用功能，如 GetAll、GetSingle、添加、编辑、删除。
现在，我是否应该设计从我的“通用数据存储库”派生的“员工数据存储库”，并在单个 class 中为上面列出的所有相关 table 添加函数，例如 GetEmployeePersonalDetail、GetEmployeeContactDetail , GetEmployeeEducation, AddEmployeePersonalDetail, EditEmployeePersonalDetail 等。通过这种方式，我从“通用数据存储库”获得的收益会非常少。另一种方法是我为每个 table 创建（并从通用存储库派生）一个单独的数据存储库，然后在业务逻辑层为“员工”创建一个 class。
编辑
如果我选择 "separate data repository for each table" 选项，在 DAL 级别，而不是 "single business logic class" 用于“员工”，如果我创建单独的业务逻辑 classes，对应于每个数据存储库，是否会考虑场景的不雅方法？
非常感谢您的指导。
如您问题的评论所述，这是我的意见。
问题：
如果您已经有了基本存储库，为什么还要为每个 table 创建特定的存储库？同样，在 BLL 中，您正在为每个存储库创建单独的 Service class（如您所提到的“业务逻辑 class”）。这都是重复工作，难以管理和理解。
建议：
您没有提到您使用的是什么 ORM（如果有的话）；所以我假设你的 ORM 提供了必要的功能来实现下面的架构。
我建议您在通用存储库中关闭 DAL。不要为特定的 tables 编写 DAL classes。您的所有服务 classes 都将使用通用 DAL 来实现基本的 CRUD 功能。所有扩展功能都应在服务 class 本身中实现。
关于服务 classes，不是为每个 Repository/Table 创建一个 class 又是重复工作。最好将相关的多个 tables（参考上一段的存储库不存在问题）分组在一项服务中。
例如，您创建为所有 table 提供基本功能的通用 DAL。您创建的 EmployeeService 涵盖所有与员工相关的 table。您创建 AccountService 涵盖所有与会计相关的 table。同样，LogService 用于所有与日志记录相关的活动。当您将所有相关成员集中在一个 class 时，这使得与服务的交互变得容易。这也减少了重复工作。
参考我的 this and this 个问题和他们接受的答案。
我希望这能解释你的担忧。
编辑 1
正如您在评论中提到的，您使用的是 EF。它支持实现我建议的必要功能。
implementing extended functionality in BLL instead of DAL will overlap the tier roles
是；确实如此。另一面也一样。当您为每个 table 编写 DAL 时，您实际上是在泄露 DAL 中的业务逻辑。如果业务逻辑有任何变化，你需要修改没有意义的DAL。
在我的建议中，即使层重叠，关注点仍然是分开的。 DAL 只处理 CRUD。 BLL 处理所有逻辑，包括数据库逻辑。
Have you used same strategy in any of your projects?
是的。在之前的一些项目中，我为每个 table 创建单独的 DAL，而不是通用 DAL。这造成了巨大的重复工作。尽管项目相对较小，但维护开销更大。几个月前，我开始了一个相对较大的项目，在那里我实施了我上面的建议。我们现在可以看到给我们带来的安慰。
在设计新的多层应用程序时，我在为我的 DAL 和 BLL 层设计做出决定时面临困难。
假设我的员工信息分布在多个 table 中，与主人 table 具有 1-1 和 1-Many 关系。下面列出了一些：
员工（硕士Table），
Employee_Contact_Detail,
Employee_Education,
Employee_Skill,
Employee_Experience
在 DAL 级别，我有一个通用数据存储库，为每个 table 提供通用功能，如 GetAll、GetSingle、添加、编辑、删除。
现在，我是否应该设计从我的“通用数据存储库”派生的“员工数据存储库”，并在单个 class 中为上面列出的所有相关 table 添加函数，例如 GetEmployeePersonalDetail、GetEmployeeContactDetail , GetEmployeeEducation, AddEmployeePersonalDetail, EditEmployeePersonalDetail 等。通过这种方式，我从“通用数据存储库”获得的收益会非常少。另一种方法是我为每个 table 创建（并从通用存储库派生）一个单独的数据存储库，然后在业务逻辑层为“员工”创建一个 class。
编辑
如果我选择 "separate data repository for each table" 选项，在 DAL 级别，而不是 "single business logic class" 用于“员工”，如果我创建单独的业务逻辑 classes，对应于每个数据存储库，是否会考虑场景的不雅方法？
非常感谢您的指导。
如您问题的评论所述，这是我的意见。
问题：
如果您已经有了基本存储库，为什么还要为每个 table 创建特定的存储库？同样，在 BLL 中，您正在为每个存储库创建单独的 Service class（如您所提到的“业务逻辑 class”）。这都是重复工作，难以管理和理解。
建议：
您没有提到您使用的是什么 ORM（如果有的话）；所以我假设你的 ORM 提供了必要的功能来实现下面的架构。
我建议您在通用存储库中关闭 DAL。不要为特定的 tables 编写 DAL classes。您的所有服务 classes 都将使用通用 DAL 来实现基本的 CRUD 功能。所有扩展功能都应在服务 class 本身中实现。
关于服务 classes，不是为每个 Repository/Table 创建一个 class 又是重复工作。最好将相关的多个 tables（参考上一段的存储库不存在问题）分组在一项服务中。
例如，您创建为所有 table 提供基本功能的通用 DAL。您创建的 EmployeeService 涵盖所有与员工相关的 table。您创建 AccountService 涵盖所有与会计相关的 table。同样，LogService 用于所有与日志记录相关的活动。当您将所有相关成员集中在一个 class 时，这使得与服务的交互变得容易。这也减少了重复工作。
参考我的 this and this 个问题和他们接受的答案。
我希望这能解释你的担忧。
编辑 1
正如您在评论中提到的，您使用的是 EF。它支持实现我建议的必要功能。
implementing extended functionality in BLL instead of DAL will overlap the tier roles
是；确实如此。另一面也一样。当您为每个 table 编写 DAL 时，您实际上是在泄露 DAL 中的业务逻辑。如果业务逻辑有任何变化，你需要修改没有意义的DAL。
在我的建议中，即使层重叠，关注点仍然是分开的。 DAL 只处理 CRUD。 BLL 处理所有逻辑，包括数据库逻辑。
Have you used same strategy in any of your projects?
是的。在之前的一些项目中，我为每个 table 创建单独的 DAL，而不是通用 DAL。这造成了巨大的重复工作。尽管项目相对较小，但维护开销更大。几个月前，我开始了一个相对较大的项目，在那里我实施了我上面的建议。我们现在可以看到给我们带来的安慰。