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

Question

我在一篇文章中读到，在.net网络应用程序的不同层之间传递数据集并不是一个好习惯。（DAL-＆gt; BAL-＆gt;页面反之亦然）。这是正确的吗？

请提出您的建议。

由于 SNA

Answer 1

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

另一方面，数据集并不关心它属于哪种数据库。你可以使用它们访问，oracle，sql server，mysql，任何东西。因此，有一些泛型可以使它们在层之间传递数据时非常有用。就像业务层不应该关心数据库细节一样，数据层不应该真正需要知道业务对象是什么，所以有一个很好的论据，你应该使用它们进行数据交换在那个级别。

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

1. 我将编写数据访问方法以返回数据表或数据引导程序，转换层将使用工厂模式将这些行转换为所需的强类型业务对象。
   或
2. 我将使用C＃迭代器块将datareader转换为数据访问层中的IEnumerable<IDataRecord>，转换层将使用它们将IEnumerable<IDataRecor>更改为IEnumerable<MyBusinessObject>，例如代码只会迭代结果集一次。

Answer 2

传递数据集没有任何问题，但这不是一个很好的做法。

<强>优点：

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

无需编写包装类

DataSet中内置了许多功能

<强>缺点：

非真正类型安全的数据类型。

您的数据字段名称可以更改应用程序的所有部分，直到它们在运行时爆炸时才能正常编译。

重物。数据集做了大量的事情，你可能不需要它的90％。

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

Answer 3

将DataSet从DAL传递到BAL没有任何问题。

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

  

我正处于“讨论”的中间   与同事谈论最好的方法   在新的实现数据层   应用

     

一种观点是数据层   应该了解业务对象   （我们自己的类代表一个   实体），并能够与之合作   本地对象。

     

相反的观点是   数据层应该是对象不可知的，   并纯粹处理简单的数据类型   （字符串，bools，日期等）

Answer 4

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

Answer 5

这样做没有根本的错误。虽然拥有DAL，BLL和UI层的基本思想是每层都可以抽象出它下面的内容。例如。 BLL不应该知道数据库是如何构建的，因为DAL将其抽象化了。如果在DAL中加载数据集然后直接通过BLL到达页面，那听起来就像BLL没有意义。

Answer 6

有关DataSet的最常见的陈述不是将其传入或传出Web服务。这不仅暴露了实现细节，还包括公开平台（.NET）的细节。

尽管可以从基础数据库中更改DataSet中的“表”和“列”名称，但您仍然主要依赖于数据库的基础结构。为了抽象，我会使用Entity Framework。例如，它允许您定义“客户”实体，该实体从多个表中获取数据并将其放入单个实体中。使用实体的代码不需要知道它是作为一个表，两个表还是其他任何方式实现的。

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

Answer 7

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

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