我的 DAL 应该返回 Person 还是 Datatable？答案

【问题标题】：Should my DAL return Person or Datatable?我的 DAL 应该返回 Person 还是 Datatable？
【发布时间】：2012-10-27 06:09:37
【问题描述】：

看完this，我还有一个问题：

我使用此代码查询数据库：

c#：

new BLL().GetPersonById(1)

BLL：

public Person GetPersonById(int id)
{
  return new DAL ().GetPersonById(1);
}

DAL：

public Person  GetPersonById(int id)
{
   // goto db and create instance of Person and fill its data...
}

但是，我做错了吗，

我的 DAL 是否应该返回 DataTable 而不是？（所以 BLL 将创建 Person ....？）

DAL：

public DataTable  GetPersonById(int id)
{
   // goto db ...
}

谢谢。

编辑：

Person 对象在 BE dll（业务实体）中定义。

【问题讨论】：

在 BLL 中返回您需要的任何内容。你的 DAL 知道 Person 吗？
@TimSchmelter 嗨，蒂姆，但是，我想知道将我的 dal 引用到 BE（实体）是否是一件坏事，因为 BLL 已经引用了它...
@TimSchmelter 是的，它引用了 BE。（实体）
就我个人而言，如果我看到DataTable 被使用at all 而没有一些非常充分的理由（主要是：如果架构完全不可预测），那么我会说有些事情是非常错误的......Person一路！但是：这里没有单一的答案。只是意见。
这有点主观。这取决于您实际需要什么以及您的类库的公开程度。你是在多个项目中使用它还是仅仅在这个项目中使用它？填充 DataTable、返回它然后将其转换为 List<Person> 既昂贵又多余。所以如果Person 是一个已知的类（或者你的 DAL 只是在这个项目中使用）你应该返回它。

【解决方案1】：

您的 DAL，确切地说是存储库，返回 Person，它是 BLL 中定义的业务对象。

BLL 不应该依赖于 DAL，最多它定义了一些将在 DAL 中实现的接口。但是，应用程序会向 DAL 请求存储的业务对象，因为它负责处理所有持久性。

是的，DAL 依赖于 BLL。 DAL 只返回应用程序对象（业务对象或视图模型），所有与持久性访问相关的内容都应隐藏。

【讨论】：

1) Person 对象是在 BE 中定义的，而不是在 BLL 中定义的。（已编辑）
@MikeSW 我的印象是 DAL 应该完全不知道 BLL，而 BLL 应该只知道 DAL 的接口。但是，他们都应该知道共享对象的定义（例如本例中的 Person）。我错了吗？
这取决于应用程序的大小。在最高级别，是的，您将拥有一个仅包含接口的公共层，然后 BL 和 DAL 将实现它们，并且没有人会相互了解，但是如果您实际上不需要它，那就有点过度设计了。

【解决方案2】：

“我的 DAL 应该返回 DataTable 吗？（所以 BLL 将创建 Person ....？）”

一点也不。理想情况下，DAL 应该处理数据库并且应该将实体/应用程序对象返回给 BAL。 DAL 用作数据库的抽象到 BLL。

我同意 MikeSW 的观点，他说“BLL 不应该依赖于 DAL，最多它定义了一些将在 DAL 中实现的接口。”

【讨论】：

为什么 DAL 应该引用 BE ？ BLL 从 DAL 的数据表创建 Person 有什么问题？
创建图层需要了解一些基本概念。不同的层用于分配应用程序的职责。万一... BLL 正在从 DLL 中获取 Datatable .... 一段时间后，如果数据库发生更改...您需要更改 DLL 和 BLL 中的逻辑.. 这不太好....否则只需要更改 DLL。这只是为什么 BLL 应该只获取实体/应用程序对象的一个例子。还有更多的东西，比如可维护性、清晰的工作流程设计、以最小的努力和副作用等改变。
PraveenPrajapati + @mike 你能去chat.stackoverflow.com/rooms/19201/…