我发现自己对 .Net 中的 DataSet/DataTable/DataRow 范式越来越不满意，主要是因为它通常比我真正想做的要复杂几个步骤。在我绑定到控件的情况下，DataSet 很好。但在其他情况下，似乎有相当多的精神开销。
我已经使用 SqlDataReader 玩了一些，这对于通过选择进行简单的短途旅行似乎很有用，但我觉得可能还有一些其他模型潜伏在 .Net 中，它们对了解更多信息很有用。我觉得我在这方面找到的所有帮助都默认使用 DataSet。也许那和 DataReader 真的是最好的选择。
我不是在寻找最好/最差的故障，只是想知道我的选择是什么以及你有什么经验。谢谢！
-埃里克·斯普尔
自从 .NET 3.5 出现以来，我一直专门使用 LINQ。真的那么好；我看不出有任何理由再使用那些旧拐杖了。
不过，与 LINQ 一样出色，我认为任何 ORM 系统都可以让您摆脱这些垃圾。
我们已经摆脱了数据集，并基于CSLA松散地构建了我们自己的 ORM 对象。您可以使用 DataSet 或 LINQ 或 ORM 完成相同的工作，但重用它（我们发现）要容易得多。'更少的代码让更多的快乐'。
我受够了 .Net 1.1 中的数据集，至少他们对其进行了优化，使其不再像大数据集那样呈指数增长。
它总是一个相当臃肿的模型——我还没有看到很多应用程序使用了它的大部分功能。
SqlDataReader 很好，但我曾经将它包装在IEnumerable<T>T 是我的数据行的某种类型表示的地方。
在我看来，Linq 是一个更好的替代品。
我一直在使用数据传输对象模式（我相信最初来自 Java 世界），使用 SqDataReader 来填充来自数据层的 DTO 集合，以便在应用程序的其他层中使用。DTO 本身是非常轻量级和简单的类，由带有获取/集的属性组成。它们可以很容易地序列化/反序列化，并用于数据绑定，使它们非常适合我的大部分开发需求。
我是SubSonic的忠实粉丝。一个编写良好的批处理/CMD 文件可以在几分钟内为您的数据库生成一个完整的对象模型；您可以将其编译成自己的 DLL 并根据需要使用它。很棒的模型，很棒的工具。该网站使它听起来像一个 ASP.NET 交易，但一般来说，如果您不尝试使用它的 UI 框架（我对此感到有点失望）或它的应用程序级自动生成工具，它几乎可以在任何地方工作.
作为记录，这里是我用来处理它的命令的一个版本（这样你一开始就不必太努力）：
sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true
每次都会这样做...然后从该目录构建 DLL ——这是 NAnt 项目的一部分，由 CruiseControl.NET 启动——然后我们就走了。我在 WinForms、ASP.NET 甚至一些命令行工具中使用它。这会产生最少的依赖关系和最大的“可移植性”（在相关项目之间，EG）。
笔记
上面的内容现在已经有一年多了。虽然我仍然非常喜欢 SubSonic，但当我有幸在 .NET 3.5 中工作时，我已经转向 LINQ-to-SQL。在 .NET 2.0 中，我仍然使用 SubSonic。所以我的新官方建议是平台版本相关的。如果是 .NET 3+，请选择接受的答案。如果是 .NET 2.0，请使用 SubSonic。
自从堆栈首次出现在多个企业项目中以来，我已经使用过类型化和非类型化 DataSet、DataViewManagers、DataViews、DataTables、DataRows、DataRowViews 以及您可以对堆栈执行的任何操作。我花了一段时间才习惯了它的工作原理。我编写了利用堆栈的自定义组件，因为 ADO.NET 并没有给我真正需要的东西。一个这样的组件比较数据集，然后更新后端存储。我真的知道所有这些项目如何运作良好，那些看过我所做的事情的人印象深刻，我设法超越那里，觉得它只对演示使用有用。
我在 Winforms 中使用 ADO.NET 绑定，并且还在控制台应用程序中使用代码。我最近与另一位开发人员合作创建了一个自定义 ORM，我们将其用于处理一个疯狂的数据模型，该模型是从承包商那里获得的，看起来与我们的普通数据存储完全不同。
我今天搜索了 ADO.NET 的替代品，但我没有看到任何我应该认真尝试学习的东西来替代我目前使用的东西。
数据集非常适合演示。
如果你让我使用它，我不知道如何处理它。
我使用 ObservableCollection
然后我又在客户端应用程序空间、WPF 和 Silverlight 中。因此，通过服务传递数据集或数据表是……恶心。
DataReader 速度很快，因为它们是结果集的只向前流。
我广泛使用它们，但我没有使用微软在框架首次推出时真正推动的任何“高级”功能。我基本上只是将它们用作哈希表列表，我觉得这非常有用。
当人们尝试创建复杂的类型化 DataSet 或尝试使用 DataSet 实际设置表之间的外键关系时，我没有看到好的结果。
当然，我是那些实际上更喜欢 DataRow 而不是实体对象实例的怪人之一。
在 linq 之前，我使用 DataReader 来填充我自己的自定义域对象的列表，但是在 linq 之后，我一直在使用 L2S 来填充 L2S 实体，或者 L2S 来填充域对象。
一旦我有更多时间进行调查，我怀疑 Entity Framework 对象将是我最喜欢的新解决方案！
选择一个现代的、稳定的、积极支持的 ORM 工具可能是对任何中等规模和复杂性的项目都能获得的最大的生产力提升。如果您得出的结论是您绝对、绝对、绝对必须编写自己的 DAL 和 ORM，那么您可能做错了（或者您正在使用世界上最晦涩的数据库）。
如果您正在处理原始数据集和行以及其他什么，请花一天时间尝试 ORM，您会惊奇地发现，如果没有将列映射到字段或一直填充的所有苦差事，您的工作效率会提高多少Sql 命令对象和我们曾经经历过的所有其他箍跳。
我爱我一些 Subsonic，但对于小规模项目以及演示/原型，我发现 Linq to Sql 也非常有用。不过，我很讨厌 EF。:P
我已经在几个项目中使用了类型化的数据集。它们很好地为数据库建模，在客户端强制实施约束，并且通常是一种可靠的数据访问技术，尤其是在 .NET 2.0 中使用 TableAdapters 的变化。
类型化的数据集在喜欢用“臃肿”之类的情感词来描述它们的人那里得到了不好的评价。我承认我更喜欢使用一个好的 O/R 映射器而不是使用 DataSet；使用对象和集合而不是类型化的 DataTables、DataRows 等只是“感觉”更好。但我发现，如果出于某种原因你不能或不想使用 O/R 映射器，类型化DataSet 是一个很好的可靠选择，它非常易于使用，并且可以让您获得 O/R 映射器的 90% 的好处。
编辑：
这里的一些人建议 DataReaders 是“快速”的替代方案。但是，如果您使用 Reflector 来查看 DataAdapter 的内部结构（DataTables 由它填充），您会发现它使用了……一个 DataReader。类型化数据集可能比其他选项具有更大的内存占用，但我还没有看到这会产生明显差异的应用程序。
使用最好的工具来完成这项工作。不要根据没有事实依据的“粗”或“臃肿”等情绪化的词语做出决定。
我只是从头开始构建我的业务对象，几乎从不使用DataTable，尤其是DataSet不再使用，除了最初填充业务对象。自己构建的优点是可测试性、类型安全和 IntelliSense、可扩展性（尝试添加到 a DataSet）和可读性（除非你喜欢阅读类似的东西Convert.ToDecimal(dt.Rows[i]["blah"].ToString())）。
如果我更聪明，我也会使用 ORM 和 3rd 方 DI 框架，但还没有感觉到需要这些。我正在做很多小型项目或对大型项目的补充。
我从不使用数据集。它们是仅可用于“演示软件”的大型重量级对象（正如有人在此处指出的那样）。这里展示了很多很棒的选择。