如果数据集应该放在数据或业务层中，我们目前正在讨论这个问题吗？
我的朋友认为所有ADO.NET组件都应该进入数据层。对我来说，这似乎不适合以下原因：
我认为数据集和数据表应该在业务逻辑中，因为它们对所有数据提供者都是通用的。数据层应该有一个Provider Factory，用于实例化正确的提供者的对象（Connection，DataAdapters，Transactions，DataReaders等）。对我来说，这是出于以下原因的方法：
一些n级专家可以帮助我们清除哪条路？提前致谢
答案 0 :(得分：5)
在我看来，根本不要使用DataSet。甚至不使用类型化的DataSet。这些是在LINQ之前创建的旧构造。跳过古代历史，进入现在时：使用LINQ to Entities和Entity Framework（EF）。两者密切相关但不尽相同。
不要在服务边界上公开EF实体。不幸的是，Microsoft在序列化实体时选择公开实现细节。除此之外，使用EF并享受比使用DataSet更多的乐趣。
答案 1 :(得分：2)
那么，隔离数据访问并不是新的：我们在15年前做到了（是的，15年前！）。
我曾经在很多地方工作，我看到了很多孤立的数据层。
但我永远不会！ - 看到数据源被替换了！
是的，我看了两次：两次，我们还替换了oudated数据层和所有toping软件......
我的回答非常简单：除非您正在为搁置软件工作，否则您可以尽可能多地隔离数据层，您将无所事事。
什么都没有，因为没有人会改变SQL Server或Oracle。无所不能，因为有人会这样做，或者他们也会重写他们的软件，或者他们会确保他们购买的产品与他们正在提供的产品兼容。
在我的书中，任何数据层都是愚蠢的。
如果您不同意，请告诉我您生命中的这一层何时将$$$保存给某人......
答案 2 :(得分：1)
我所在的地方，我们将数据集，数据表，数据行和数据集从数据层返回到业务层。
基本原理是这些类型不是特定于db风格的。无论您使用mysql，access，sql server，oracle还是数据集都是数据集，因此可以从根级数据层返回。
然后，业务层获取此原始数据并将其转换为强类型业务对象 - 应用任何必要的业务规则 - 以交给表示层。
编辑：在查看一些代码时，我们不会使用完整的数据集。它主要是数据表和数据引导器。
答案 3 :(得分：0)
一种典型的方法是在业务逻辑层/域中公开聚合根（如Customer）存储库接口，并在数据访问层/基础结构中实现具体的存储库。
答案 4 :(得分：0)
我对DataSet的基本问题是它们的结构是数据库模式的精确镜像。
如果将DataSet公开给实际的页面呈现代码，则可以有效地将数据库模式（产品的最终后端）公开给表示层。现在明显的问题可能发生：在轨道的后面，您将需要重构底层数据模式，并且由于设计，您需要将更改应用于系统中的所有其他层。这是封装的一个主要例子，当它真的应该被使用时。
如果您要使用DataSet，请将DataSet隐藏在数据访问层中，并将一组概念业务对象公开给表示层。您公开的业务对象集应该根据良好的面向对象的主体来设计，这与良好的关系数据库设计原则完全不同。
答案 5 :(得分：-1)
我必须同意不使用dataSets。我在其中工作的一个应用程序是Data Layer和Application层中的DataSet。 DataLayer DataSet与DataBase匹配，其中Application层数据集对信息进行非规范化，使其更容易被前端消耗。