一个数据访问层服务于多个业务层?或不?

Posted

技术标签:

【中文标题】一个数据访问层服务于多个业务层?或不?【英文标题】:One Data Access Layer serving multiple Business Layers? or not? 【发布时间】:2012-11-26 23:57:32 【问题描述】:

我拥有(或将拥有)一个 DAL,其中包含我的 ERP 系统的数据访问方法。

在业务方面,有些上下文将使用此 DAL。例如:条形码应用程序、自定义销售拣货应用程序、采购订单应用程序。

我正在考虑而不是为我的业务层创建一个 DLL 来将其分解为这些主要区域,从而使它们与 DAL 进行可靠的通信。这将有助于减少我完成的应用程序的臃肿

这是我的第一个问题,第二个问题是业务层之间共有的数据访问对象是否应该驻留在单独的项目中以便所有 BL 都可以访问?

最后,这些数据访问对象对 DAL 也很有用,因为许多方法将这些对象的列表返回给业务层或直接返回给 Presentation(不常见但会发生)。它们是否应该引用具有 DAO 的同一个公共类?

【问题讨论】:

【参考方案1】:

我认为你的第二个问题的答案是相当清楚的; DAL 应该有自己的项目。

至于第一个,这实际上取决于在不同的应用程序需求之间有多少共性。您还需要考虑拆分成多个 BLL DLL 是否会增加业务逻辑维护的复杂性。

对于从同一 UI 访问 DAL 和 BLL 的最后一项,我会敦促您谨慎行事。这意味着您可能对两者都有依赖。将简单的方法放入 BLL 中可能会更好,这些方法只调用 DAL 功能并返回答案,以便一切从 ​​UI 到 BLL 再到 DAL。

当然,对于所有这些事情,您需要考虑哪些答案最适合您的应用程序和开发方法。

【讨论】:

例如,如果我有一个名为 Employee 的类,并且我希望我的 BLL 和 DAL 能够访问它,我应该怎么做?我怎样才能避免它?我不希望我的 DAL 方法返回数据表,我想返回员工记录,BLL 对它们执行一些逻辑并与 UI 进行通信..【参考方案2】:

您可以拥有 DAO 和 BL 都可以使用的域对象。领域对象应该是非常愚蠢的,它应该只是一个给定实体的表示。

例子:

Bl.Get-employee -->返回域对象员工

BL.Get-Employee 方法调用将您的数据挖掘转换为域对象的 DAO,在本例中为 Employee 域对象。

Bl.Get-employee>>调用 DOA.Get-employee。 所有数据库操作都应由您的 DAO 处理。

在您有业务逻辑的场景中,您的代码可能如下所示。

Employee Bl.ProcessRecord(EmployeeDomain Employee)

    //Do some logic....
    //Perhaps interact with other DAO operations
    //Have some business logic operations ETC
    Persist your changes to the database
    Employee = DAO.Save-employee(Employee)
    return Employee;
 

【讨论】:

以上是关于一个数据访问层服务于多个业务层?或不?的主要内容,如果未能解决你的问题,请参考以下文章

ASP WebApi:服务层、业务层和数据访问层

业务逻辑层应该访问数据库/数据访问层吗?

用于业务逻辑或数据访问层的 Web 服务

一个基于EntityFramework Core的简单数据库访问层,适用于轻量级数据库业务

一个基于EntityFramework Core的简单数据库访问层,适用于轻量级数据库业务

Spring数据访问和数据访问层与业务或服务层之间的交互