我们目前正在讨论数据集应该放在数据层还是业务层？
我的朋友认为所有 ADO.NET 组件都应该放在数据层中。对我来说，这似乎不正确，原因如下：
我认为数据集和数据表应该在业务逻辑中，因为它们对所有数据提供者都是通用的。数据层应该有一个提供者工厂来实例化正确的提供者的对象（连接、数据适配器、事务、数据读取器等）。对我来说，这是要走的路，原因如下：
有没有n级的大师能帮我们弄清楚该走哪条路？
在我看来，根本不要使用 DataSet。甚至不要使用类型化的 DataSet。这些是在 LINQ 之前创建的旧结构。跳过古代历史，进入现在时：使用 LINQ to Entities 和实体框架 (EF)。两者密切相关，但并不相同。
不要跨服务边界公开 EF 实体。不幸的是，微软选择在序列化实体时公开实现细节。除此之外，使用 EF 并获得比使用 DataSet 更多的乐趣。
好吧，隔离数据访问并不是什么新鲜事：我们在 15 年前就这样做了（是的，15 年前！）。
我在很多地方工作过，我看到了很多孤立的数据层。
但我从来没有——从来没有！-- 看到一个数据源被替换了！
是的，我看过两次：而且两次，我们还更换了过期的数据层和所有顶级软件......
我的回答很简单：除非你正在为搁置软件工作，否则你可以尽可能多地隔离数据层，你将一无所获。
没有人会因为改变而改变 SQL Server 或 Oracle。并且因为有一天有人会这样做，他们要么会重写他们的软件，要么会确保他们购买的产品与他们离开的产品兼容。
在我的书中，任何数据层都是愚蠢的。
如果您不同意，请告诉我在您的生活中，这一层何时会为某人节省 $$...
我在哪里，我们将数据集、数据表、数据行和数据读取器从数据层返回到业务层。
理由是这些类型不是特定于 db-flavor 的。无论您使用 mysql、access、sql server、oracle 还是任何数据集都是数据集，因此可以从根级数据层返回。
然后，业务层获取这些原始数据并将其转换为强类型业务对象——应用任何必要的业务规则——交给表示层。
编辑：当我查看一些代码时，我们并没有太多使用完整的数据集。它主要是数据表和数据读取器。
一种典型的方法是在您的业务逻辑层/域中公开一个聚合根（如客户）存储库接口，并在您的数据访问层/基础设施中实现具体的存储库。
我对 DataSet 的基本问题是它们的结构是数据库模式的精确镜像。
如果您将 DataSet 暴露给实际的页面呈现代码，那么您实际上是将数据库模式（产品的最终后端）暴露给表示层。现在可能会出现明显的问题：稍后您将需要重新构建底层数据模式，并且由于设计原因，您需要将更改应用于系统中的所有其他层。这是一个真正应该使用的封装没有被使用的典型例子。
如果您打算使用数据集，请将数据集直接隐藏在数据访问层中，并向表示层公开一组概念业务对象。您公开的业务对象集应根据良好的面向对象原则设计，这与良好的关系数据库设计原则完全不同。
我必须同意根本不使用数据集。我在其中工作的应用程序之一是数据层和应用程序层中的数据集。DataLayer 数据集与数据库相匹配，其中应用层数据集对信息进行了非规范化处理，以使其更适合前端使用。