将数据集传递到不同的层（设计相关）答案

【问题标题】：Passing dataset to different layers(design related)将数据集传递到不同的层（设计相关）
【发布时间】：2009-06-04 12:32:18
【问题描述】：

我在一篇文章中读到，在 .net Web 应用程序的不同层之间传递数据集不是一个好习惯。（DAL->BAL->Pages 反之亦然）。正确吗？

请提出您的建议。

谢谢国民经济核算体系

【问题讨论】：

标签： asp.net

【解决方案1】：

一方面，数据集和数据表的问题在于它们在数据访问层之外暴露了数据库实现细节，例如列名和类型。更改数据库或查询中的列名，并且更改也很可能传播到您的数据集，从而强制重新编译使用该数据集的任何层。因此，如果您将数据检索到数据集中，您应该在传递数据之前将其转换为使用强类型业务对象。

另一方面，数据集并不关心它属于哪种数据库。您可以将它们与 access、oracle、sql server、mysql 等任何东西一起使用。所以有一些通用性可以使它们在层之间传递数据时有用。就像业务层不应该关心数据库细节一样，数据层不应该真的需要知道业务对象是什么，所以有一个很好的论点是您应该将它们用于数据交换在那个级别。

我的正常程序是在业务层和数据访问层之间设置一种单向“转换”层，以便业务层仅处理业务对象和数据层only 返回通用数据。这目前采用以下两种形式之一：

我将编写我的数据访问方法以返回数据表或数据读取器，转换层将使用工厂模式将这些行转换为所需的强类型业务对象。
或
我将使用 C# 迭代器块将数据读取器转换为数据访问层中的 IEnumerable<IDataRecord>，然后转换层将使用它们将 IEnumerable<IDataRecor> 更改为 IEnumerable<MyBusinessObject>，这样代码就只会迭代超过结果集一次。

【讨论】：

为什么数据集必须是数据库的副本。它的数据集设计可以由 UI 和业务逻辑需求驱动。将其放入 db 的逻辑可以在 DAL 中处理。总结一下为什么不能将数据集（或类型化数据集）用作业务实体？
数据集没有有来模拟数据库。这就是我第二段的重点。但是，如果您查看那里的代码，我想您会发现通常会发生这种情况。

【解决方案2】：

传递数据集并没有错，但这不是一个好习惯。

优点：

易于在 .NET 应用程序中传递和使用

无需编写包装类代码

DataSet 中内置了许多功能

缺点：

不是真正类型安全的数据类型。

您的数据字段名称可以更改您应用的所有部分都可以正常编译，直到它们在运行时崩溃。

重物。数据集做了很多事情，而你可能不需要其中的 90%。

让非 .NET 应用与您的 DAL 或 BAL 通信会非常干净。

【讨论】：

【解决方案3】：

将数据集从 DAL 传递到 BAL 并没有错。

我认为关于 DAL 最佳实践的 this stackoverflow question 很好地总结了这两种思想流派。

我正在进行“讨论” 和同事讨论最好的方法以新的方式实现数据层应用。

一种观点是数据层应该知道业务对象（我们自己的类代表一个实体），并能够使用它本机对象。

相反的观点是数据层应该与对象无关，并纯粹处理简单的数据类型（字符串、布尔值、日期等）

【讨论】：

【解决方案4】：

跨层传递数据集没有问题。如果你观察，你会注意到传递数据集是通过引用而不是通过值。所以这里没有性能问题。现在您阅读的内容也是正确的，但是您必须了解上下文。如果您要跨越远程边界传递数据集，则不建议这样做。

【讨论】：

不复制数据并不意味着没有性能问题。使用数据集意味着将整个结果集保存在内存中，这可能会导致问题。 Datareaders 和 IEnumerables 通常是更好的选择。
此外，具体的关注点更多地与耦合有关，而不是与性能有关。首先获得数据集的正常方式是 sql 查询的结果。您可以将它们用于其他事情，但这不太常见。将这些查询结果的数据集版本围绕数据层的实现细节传递给其他层。
虽然内存中可能存在大量数据，但断开式架构的优势不容忽视。我不否认耦合问题。但是，通过对设计的适当考虑，我们可以解决以 SQL 查询结束的正常问题。与正常的业务实体相比，我们还具有数据集功能在我们使用时的额外优势（约束等）。我同意它可能不适合所有类型的应用程序，但根据具体情况，数据集比业务实体具有明显优势。

【解决方案5】：

这样做从根本上没有错。尽管拥有 DAL、BLL 和 UI 层的基本思想是让每一层都可以抽象出它下面的内容。例如。 BLL 不应该对数据库的结构有任何了解，因为 DAL 将其抽象出来。如果在 DAL 中加载数据集，然后直接通过 BLL 传递到页面，听起来 BLL 毫无意义。

【讨论】：

【解决方案6】：

关于 DataSet 的最有力的陈述是不要将它传入或传出 Web 服务。这不仅仅是公开实现细节，还包括公开平台 (.NET) 的细节。

虽然可以从底层数据库中更改 DataSet 中的“表”和“列”名称，但您仍然很大程度上受制于数据库的底层结构。为了抽象，我会使用实体框架。例如，它允许您定义一个“客户”实体，该实体从多个表中获取数据并将其放入单个实体中。使用实体的代码不需要知道它是实现为一个表、两个表还是其他。

即便如此，您也不应该将这些实体传递到 Web 服务边界之外。他们仍然在实现之外传递实现细节。例如，基类的属性会被序列化，即使这些只是实现细节。

【讨论】：

【解决方案7】：

据我了解，DataSet 需要打开 db 连接，只要它被使用，这会降低应用程序的性能，因为它会保持连接打开直到内容被呈现。

相反，我建议使用泛型集合，例如 IEnumerable<myType> 或 IQueryable<myType>，其中 myType 是您使用数据填充的自定义类型。

【讨论】：

您可能会想到 DataReader。数据集本地存储在内存中，不需要打开数据库连接。