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