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