在设计新的多层应用程序时，我很难为 DAL 和 BLL 层设计做出决定。
假设我将员工信息分布在多个表中，这些表与主表具有1-1和1-Many关系。下面列出的几个：
员工（主表），
Employee_Contact_Detail，
Employee_Education，
Employee_Skill，
Employee_Experience
在DAL级别，我有一个通用数据存储库，为每个表提供GetAll，GetSingle，Add，Edit，Delete等常用功能。
现在，我应该设计从我的“通用数据存储库”派生的“员工数据存储库”，并在单个类中添加上面列出的所有相关表的函数，如GetEmployeePersonalDetail，GetEmployeeContactDetail，GetEmployeeEducation，AddEmployeePersonalDetail，EditEmployeePersonalDetail等。这样我对“通用数据存储库”的收益会少得多。另一种方法是我为每个表创建（并从Generic Repository派生）一个单独的数据存储库，然后在业务逻辑层为“Employee”创建一个单独的类。
修改
如果我选择“每个表的单独数据存储库”选项，在DAL级别，而不是“Employee”的“单个业务逻辑类”，如果我创建单独的业务逻辑类，对应于每个数据存储库，是否会采取不雅的方法来考虑这种情况？
非常感谢你的指导。
答案 0 :(得分：1)
正如您对问题的评论所述，这是我的意见。
如果您已有基本存储库，为什么要为每个表创建特定的存储库？同样，在BLL中，您将为每个存储库创建单独的Service类（＆＃34;业务逻辑类＆＃34;如您所述）。这都是重复工作，难以管理和理解。
您没有提到您正在使用的ORM（如果有）;所以我假设您的ORM提供了在架构下实现的必要功能。
我建议你在通用存储库关闭你的DAL。不要为特定表编写DAL类。您的所有服务类都将使用通用DAL来实现基本的CRUD功能。所有扩展功能都应该在Service类本身中实现。
关于服务类，而不是为每个Repository / Table创建一个类再次重复工作。在一个服务中，更好地将您的相关多个表（存储库在上面的段落中引用是不可能的）分组。
例如，您创建了为所有表提供基本功能的通用DAL。您创建涵盖所有员工相关表的EmployeeService。您创建涵盖所有会计相关表的AccountService。同样，LogService用于所有与日志记录相关的活动。当您在一个类中获得所有相关成员时，这使得与服务的交互变得容易。这也减少了重复工作。
我希望这能解释你的担忧。
正如您的评论所述，您是我们的EF。它支持实现我建议的必要功能。
在BLL而不是DAL中实现扩展功能将重叠层角色
是;它确实。其他方面也一样。当您为每个表编写DAL时，实际上是在DAL中泄露了Business Logic。如果业务逻辑发生任何变化，您需要修改无意义的DAL 在我的建议中，即使图层重叠，问题仍然是分开的。 DAL只处理CRUD。 BLL处理所有逻辑，包括数据库逻辑。
您是否在任何项目中使用过相同的策略？
是。在之前的一些项目中，我为每个表而不是通用DAL创建了单独的DAL。这导致了巨大的重复工作。尽管项目相对较小，但维护费用更高。几个月前，我从一个相对较大的项目开始，我实施了上面提到的建议。我们现在可以看到给予我们的宽慰。