1

在设计一个新的多层应用程序,我面临的困难在决定为我的DALBLL层设计单/多数据存储库。设计DAL和BLL - 对相关表

假设我将员工信息分散在多个表中,这些表具有与主表的1-1和1-多关系。很少有如下所列:

员工(主表),
Employee_Contact_Detail,
Employee_Education,
Employee_Skill,
Employee_Experience

在DAL水平,我有一个通用的数据存储库提供诸如GETALL常用功能, GetSingle,添加,编辑,删除每个表。

现在,我要设计我的“员工资料库”从我的“通用数据仓库”派生并添加功能像GetEmployeePersonalDetail,GetEmployeeContactDetail,GetEmployeeEducation,AddEmployeePersonalDetail,EditEmployeePersonalDetail等单一类上面列出在这所有相关表对于“通用数据存储库”,我将获得的好处更少。另一种方法是我为每个表创建(并从Generic Repository派生)一个单独的数据存储库,然后在“Employee”的业务逻辑层创建一个类。

编辑

如果我去了选项“为每个表单独的数据存储库”,在DAL水平,然后,而不是“单一的商业逻辑类”的“雇员”,如果我创建独立的业务逻辑与每个数据存储库相对应的类是否会采取不雅的方法来观察场景?

非常感谢您的指导。

+0

你打算做什么没有错。这个问题没有任何具体的答案。所有答案都将基于意见。所以,你最好关注你的需求而不是模式。模式可以解决我们的问题。如果有什么解决你的问题,那么这是你的模式。 –

+0

@A_J,非常感谢您的意见。我已经提出了一些问题。 – developer

回答

1

正如您在提问中所提到的,这是我的看法。

问题:

如果你已经有了基础信息库,为什么每个表创建特定的仓库?再次,在BLL中,您正在为每个存储库创建单独的Service类(如您所述的“业务逻辑类”)。这是一件重复的工作,难以管理和理解。

建议:

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

关于服务类,而不是为每个存储库/表创建一个类是再次重复的工作。在一个服务中更好地分组您的相关多个表(参考以上段落时存储库无疑)。

例如,您可以创建通用DAL,为所有表提供基本功能。您创建EmployeeService,涵盖所有与员工相关的表格。您创建了覆盖所有会计相关表的AccountService。同样,LogService适用于所有与伐木有关的活动。当你在一个类中获得所有相关成员时,这使得与服务交互变得容易。这也减少了重复工作。

请参阅我的thisthis问题及其接受的答案。

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

编辑1

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

实现在BLL代替DAL扩展功能将重叠层角色

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

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

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

+0

谢谢你的建议,这似乎很有用;编码少,并发症少。我唯一担心的是,在BLL而不是DAL中实现扩展功能将重叠层角色,并且我不确定项目的增长能否继续使用相同的策略而没有任何复杂性。你有没有在你的任何项目中使用相同的策略?顺便说一句,我正在使用EF6。 – developer

+0

非常感谢您分享您的经验给我更多的信心。 – developer