首页 文章

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

提问于
浏览 次
3

我有（或将要）一个DAL包含我的ERP系统的数据访问方法 .

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

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

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

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

c# .net architecture data-access-layer business-logic-layer

2 回答

  • 1

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

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

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

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

    回复于
  • 1

    您可以拥有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;
}
    回复于

相关问题