C＃：除了DataSet之外你还能使用什么？
我发现自己对.Net中的DataSet / DataTable / DataRow范例越来越不满意，主要是因为它通常比我真正想做的事情复杂几步。 在我绑定到控件的情况下，DataSet也没问题。 但在其他情况下，似乎有相当数量的心理开销。
我已经玩了一些SqlDataReader，这似乎对于通过选择的简单短途旅行很有用，但我觉得可能有一些潜伏在.Net中的其他模型对于了解更多信息很有用。 我觉得我发现的所有帮助都默认使用DataSet。 也许这和DataReader确实是最好的选择。
我不是在寻找最好/最差的故障，只是好奇我的选择是什么，以及你对它们的体验。 谢谢！
-Eric Sipple
自.NET 3.5问世以来，我一直使用LINQ。 这真的很棒; 我认为没有任何理由再使用这些旧拐杖了。
然而，就像LINQ一样，我认为任何ORM系统都可以让你消除那个残骸。
我们已经远离数据集并基于CSLA松散地构建了我们自己的ORM对象。 您可以使用DataSet或LINQ或ORM完成相同的工作，但重新使用它（我们已经发现）要容易得多。 ‘少代码让你更开心’。
我厌倦了.Net 1.1中的DataSet，至少他们对它进行了优化，以便它不再以大型集合的指数速度减速。
它总是一个相当臃肿的模型 – 我没有看到许多应用程序使用其大部分function。
SqlDataReader很好，但我曾经将它包装在IEnumerable ，其中T是我的数据行的某种类型表示。
在我看来，Linq是一个更好的替代品。
我一直在使用数据传输对象模式（最初来自Java世界，我相信），使用SqDataReader从数据层填充DTO集合，以便在应用程序的其他层使用。 DTO本身是非常轻量级的简单类，由带有gets / sets的属性组成。 它们可以很容易地序列化/反序列化，并用于数据绑定，使它们非常适合我的大多数开发需求。
我是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非常适合演示。
如果你让我使用它，我不知道如何处理它。
我使用ObservableCollection
然后我再次进入客户端应用程序空间，WPF和Silverlight。 因此，通过服务传递数据集或数据表是……粗略的。
DataReader很快，因为它们只是结果集的前向流。
我使用了类型化和非类型化的DataSet，DataViewManagers，DataViews，DataTables，DataRows，DataRowViews，以及几乎可以对堆栈做的任何事情，因为它在多个企业项目中首次出现。 我花了一段时间才习惯它是如何工作的。 我编写了利用堆栈的自定义组件，因为ADO.NETdid并不能完全满足我的需求。 一个这样的组件比较DataSet，然后更新后端存储。 我真的知道所有这些项目是如何运作良好的，那些已经看到我所做的事情给我留下了深刻的印象，我设法超越那里感觉它只对演示使用有用。
我在Winforms中使用ADO.NET绑定，我也使用控制台应用程序中的代码。 我最近与另一个开发人员合作创建了一个自定义ORM，我们用它来对付一个疯狂的数据模型，我们从承包商那里看到的东西与我们的普通数据存储区完全不同。
我今天搜索了ADO.NET的替代品，我没有看到任何我应该认真学习替换我目前使用的东西。
我广泛使用它们，但我没有使用微软在框架刚出现时真正推动的任何“高级”function。 我基本上只是将它们用作Hashtables列表，我发现它非常有用。
当人们试图制作复杂的类型化数据集时，或者尝试使用DataSet实际设置表之间的外键关系时，我没有看到好的结果。
当然，我是一个奇怪的人，实际上更喜欢DataRow到实体对象实例。
Pre linq我使用DataReader来填充我自己的自定义域对象的列表，但是发布linq我一直在使用L2S来填充L2S实体，或者使用L2S来填充域对象。
一旦我有更多时间进行调查，我怀疑Entity Framework对象将是我最喜欢的解决方案！
选择一个现代的，稳定的，积极支持的ORM工具可能是生产力的最大提升，几乎任何中等规模和复杂性的项目都可以获得。 如果你的结论是绝对的，绝对必须编写自己的DAL和ORM，那么你可能做错了（或者你正在使用世界上最模糊的数据库）。
如果你正在做原始数据集和行而不是什么，那么花一天时间去尝试一个ORM，你会惊讶于你可以提高效率，而不是把所有的苦差事都映射到字段或者一直填写Sql命令对象和所有其他箍跳我们都曾经历过。
我爱我一些Subsonic，虽然对于小型项目以及演示/原型，我发现Linq对Sql非常有用。 虽然我很讨厌EF。 ：P
我已经为几个项目使用了类型化的DataSet。 他们很好地建模数据库，在客户端强制执行约束，并且通常是一种可靠的数据访问技术，尤其是.NET 2.0和TableAdapter的变化。
类型化的数据集从那些喜欢用“臃肿”这样的情感词来描述它们的人那里得到了糟糕的说唱。 我会批准我喜欢使用一个好的O / R映射器而不是使用DataSet; 它只是“感觉”更好地使用对象和集合而不是类型化DataTables，DataRows等。但我发现，如果由于某种原因你不能或不想使用O / R映射器，键入DataSet是一个很好的可靠选择，易于使用，可以获得O / R映射器的90％的好处。
编辑：
有人建议DataReader是“快速”替代品。 但是如果你使用Reflector来查看DataAdapter的内部（DataTables被填充），你会发现它使用了……一个DataReader。 类型化的DataSet 可能比其他选项具有更大的内存占用，但我还没有看到应用程序在哪里产生了实质性的差异。
使用最好的工具来完成工作。 不要根据没有事实基础的“粗暴”或“膨胀”等情绪化词语做出决定。
我只是从头开始构建我的业务对象，几乎从不使用DataTable，特别是不再使用DataSet，除了最初填充业务对象。 构建自己的优点是可测试性，类型安全性和智能感知，可扩展性（尝试添加到DataSet）和可读性（除非您喜欢阅读Convert.ToDecimal（dt.Rows [i] [“blah”]之类的东西.ToString（） ））。
如果我更聪明，我也会使用ORM和第三方DI框架，但还没有觉得有必要。 我正在做大量规模较小的项目或大型项目的补充。
我永远不会使用数据集。 它们是大型重量级物体，只能用于“demoware”（如此处有人指出）。 这里展示了很多很好的选择。