3

我有（或将有）一个 DAL，其中包含我的 ERP 系统的数据访问方法。

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

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

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

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

4

2 回答 2

1

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

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

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

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

于 2012-12-09T11:53:21.077 回答
1

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

例子：

Bl.Get-employee --> 返回域对象 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;
}
于 2012-12-09T18:40:37.697 回答