C# 业务层（BLL）数据访问层（DAL）和UI之间的公共结构？

我希望我的所有层BLL、DAL和UI共享类（具体或接口）

这真的是一种糟糕的做法吗

我不喜欢从DAL方法返回数据表，而是返回BLL可以直接使用的对象

我想有一个单独的VS项目，其中包含所有层都应该知道的类

示例：我想定义一个所有层都应该知道的lot类。UI应该能够接收批次类，以便显示或允许用户提交要处理的批次。DAL还应该能够使用lot类查询数据库并返回它们。另一方面，BLL应该获得这些地段，并对其应用业务规则

如果这是完全错误的，有什么替代方案

我希望我的所有层BLL、DAL和UI共享类（具体的或抽象的） 接口）

这取决于什么类型的类。如果您需要它们来访问公共域实体，那么请确保

重要的部分是允许这些层对这些类执行什么操作。如果没有经过一些集中的业务逻辑，您的客户机/用户界面层不应该能够修改域实体（并持久化它们）。这意味着您的DAL不应该被您的UI访问，尽管它们可以共享公共实体、接口等

常见的方法如下所示：

UI->BLL->DAL->持久性存储（数据库、文件等）

这些层中的每一层都可以访问commmon类。只要用户界面不能直接访问DAL，你就可以了。对此，您有两种选择：

• 通过服务（WCF等）访问BLL
• 将DAL和BLL放在同一个项目中，并将DAL设置为内部，以便只有BLL可以访问它

你最终会得到这样的结果：

UI->Service->BLL->DAL->持久性存储（数据库、文件等）

我强烈推荐马丁·福勒。它将为你的应用程序分层提供良好的基础。 我不希望从DAL方法返回数据表，而是希望 返回BLL可以直接使用的对象

---

那是个好主意。这就是我们的想法发挥作用的地方。DAL通常知道如何与DB对话，并且DAL还知道如何将特定于DB的结构转换为您的域模型。域实体进入和退出DAL。在DAL中，当持久化数据时，域实体被转换为特定于DB的结构。反之亦然：当BLL请求数据时，DAL检索数据并将其转换为域实体，然后再将其传回。

为了快速回答您的问题，通常人们创建类和/或 要在DAL BLL之间通信的对象