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

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

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

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

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

---

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

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

至于第一个，这实际上取决于不同的应用程序需求之间有多少共性。您还需要考虑是否将多个BLL DLL转换为维护业务逻辑的复杂性。 我强烈建议您在从同一UI访问DAL和BLL的最后一项时要谨慎。这意味着你可以同时依赖于这两者。最好将简单的方法放入BLL中，只调用DAL功能并返回答案，以便从UI到BLL再到DAL

---

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

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

例如：

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

Get-Employee方法调用DAO，该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;
} 

---

例如，如果我有一个名为Employee的类，我希望我的BLL和DAL能够访问它，我应该如何做？我怎样才能避免呢？我不希望我的DAL方法返回数据表，我希望返回员工记录，并对其执行一些逻辑并与UI通信。。