Question

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

商业方面，有使用此DAL的上下文。示例包括：条形码应用程序，自定义销售挑选应用程序，采购订单应用程序。

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

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

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

Answer 1

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

至于第一个，它实际上取决于不同应用程序需求之间的共同程度。您还需要考虑是否将spilitting到多个BLL DLL中会增加维护业务逻辑的复杂性。

我建议您在最后一项访问DAL以及同一UI的BLL时要小心。这意味着您可以依赖两者。将简单方法放入BLL中可能会更好，它只调用DAL功能并返回答案，以便从UI到BLL再到DAL。

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

Answer 2

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

示例：

Bl.Get-employee - ＆gt;返回域对象员工

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

Bl.Get-employee＆gt;＆gt;致电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;
}

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

2 个答案: