我想让我的BLL、DAL和UI层共享类（具体或接口）。
这真的是个不好的做法吗？
我不想从我的DAL方法中返回数据表，而是返回BLL可以直接使用的对象。
我希望有一个单独的VS项目，其中包含所有层都应该了解的类。
例如：我想定义一个批次类，所有层都应该知道。 UI应该能够接收批次类以便显示或使用户提交要处理的批次。此外，DAL应该能够使用批次类查询数据库并返回它们。另一方面，BLL应该获取这些批次并对其应用业务规则。
如果这完全是错误的，那么有什么替代方案呢？
2个回答
5
我希望我的所有层（BLL、DAL和UI）都能共享类（具体或接口）。
这取决于类的类型。如果您需要它们都访问共同的域实体，那么可以肯定地使用。
重要的部分是您允许这些层使用这些类的方式。您的客户端/UI层不应该能够修改域实体（并将其持久化）而不经过一些集中的业务逻辑。这意味着您的DAL不应该被UI访问，尽管它们可以共享公共实体、接口等。
一个常见的方法是这样的：
UI -> BLL -> DAL -> 持久化存储（数据库、文件等）
每个层都可以访问共同的类。只要UI不能直接访问DAL，您就应该没问题。您有几个选项：
- 通过服务（WCF等）使BLL可访问 - 将DAL和BLL放在同一个项目中，并使DAL为内部，以便只有BLL可以访问它
最终您会得到如下结果：
这取决于类的类型。如果您需要它们都访问共同的域实体，那么可以肯定地使用。
重要的部分是您允许这些层使用这些类的方式。您的客户端/UI层不应该能够修改域实体（并将其持久化）而不经过一些集中的业务逻辑。这意味着您的DAL不应该被UI访问，尽管它们可以共享公共实体、接口等。
一个常见的方法是这样的：
UI -> BLL -> DAL -> 持久化存储（数据库、文件等）
每个层都可以访问共同的类。只要UI不能直接访问DAL，您就应该没问题。您有几个选项：
- 通过服务（WCF等）使BLL可访问 - 将DAL和BLL放在同一个项目中，并使DAL为内部，以便只有BLL可以访问它
最终您会得到如下结果：
UI -> Service -> BLL -> DAL -> 持久化存储（数据库、文件等）
我强烈推荐 Martin Fowler 的 企业应用架构模式。它将为您提供一个良好的应用程序分层基础。
我更喜欢不要从我的 DAL 方法中返回数据表，而是返回 BLL 可直接使用的对象。
这是个好主意。这就是 ORM 的作用所在。DAL 通常知道如何与数据库交互，并且还知道如何将特定于数据库的结构转换为您的领域模型。领域实体进入和退出 DAL。在 DAL 中，领域实体在持久化数据时被转换为特定于数据库的结构。反之亦然：当 BLL 请求数据时，DAL 检索数据并在传递回来之前将其转换为领域实体。
- Bob Horn
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接