4

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

这真的是一个坏习惯吗？

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

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

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

如果这是完全错误的，还有哪些选择？

4

2 回答 2

5

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

这取决于什么类型的类。如果您需要它们来访问公共域实体，那么当然可以。

重要的部分是您允许这些层对这些类做什么。您的客户端/UI 层不应该通过一些集中的业务逻辑来修改域实体（并保留它们）。这意味着您的用户界面不应访问您的 DAL，尽管它们都可以共享通用实体、接口等......

一种常见的方法是这样的：

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

这些层中的每一层都可以访问公共类。只要 UI 不能直接访问 DAL，就应该没问题。为此，您有几个选择：

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

你最终会得到类似的东西：

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

我强烈推荐Martin Fowler的企业应用架构模式。它将为您分层应用程序提供良好的基础。

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

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

于 2012-12-09T19:06:31.083 回答
1

为了快速回答您的问题，人们通常会创建POCO类和/或DTO 对象以在 DAL <-> BLL 之间进行通信

于 2012-12-09T19:15:29.580 回答