一个数据访问层服务多个业务层？是还是不是？

Question

我有一个包含ERP系统数据访问方法的DAL（数据访问层）。

从业务角度来看，有一些上下文将使用此DAL。例如：条形码应用程序、定制销售拣选应用程序、采购订单应用程序。

我在考虑将我的业务层分解为这些主要区域的一个DLL，以便它们与DAL独立通信。这将有助于减少我的完成应用程序的膨胀。

这是我的第一个问题，第二个问题是，是否应将在业务层之间共享的数据访问对象放置在单独的项目中，以便所有业务层都可以访问？

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

- e4rthdog

Answer 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;
} 

- CodeMilian

Answer 2

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

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

我建议您在最后一项访问DAL以及BLL时要谨慎。这意味着您可能对两者都有依赖性。最好将简单的方法放入BLL中，只调用DAL功能并返回答案，以便所有内容从UI到BLL再到DAL。

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

- kevinw

---

如果我有一个名为Employee的类，并且我希望我的BLL和DAL可以访问它，我该如何做？我如何避免这种情况？我不想让我的DAL方法返回数据表，而是想返回员工记录，然后由BLL对它们进行一些逻辑处理并与UI通信。 - e4rthdog