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