我发现自己对.Net中的DataSet / DataTable / DataRow范例越来越不满意，主要是因为它通常比我真正想做的要复杂得多。在我绑定到控件的情况下，可以使用数据集。但是在其他情况下，似乎还有很多精神上的负担。

我已经使用SqlDataReader进行了一些操作，这对于通过选择进行简单的干扰似乎很有用，但是我觉得.Net中可能还存在其他一些模型，这些模型对于了解更多信息很有用。我觉得我在此方面找到的所有帮助都默认情况下仅使用DataSet。也许那和DataReader确实是最好的选择。

我不是在寻找最佳/最坏的分类，只是想知道我的选择是什么，以及我们在这些选择方面的经验。谢谢！

埃里克·西普尔(Eric Sipple)

解决方案

回答

自从.NET 3.5发布以来，我一直只使用LINQ。真的很好。我看不出有任何理由再使用这些旧拐杖。

尽管与LINQ一样强大，但我认为任何ORM系统都可以使我们摆脱麻烦。

回答

我们已经远离数据集，并根据CSLA松散地构建了自己的ORM对象。我们可以使用DataSet或者LINQ或者ORM来完成相同的工作，但是重用它(我们发现)要容易得多。 "更少的代码会使人更快乐"。

回答

我广泛使用了它们，但没有使用微软在框架首次发布时真正推动的"高级"功能。我基本上只是将它们用作哈希表列表，我发现它们非常有用。

当人们尝试制作复杂类型的数据集或者试图在具有数据集的表之间建立外键关系时，我没有看到良好的结果。

当然，我是实际上更喜欢DataRow而不是实体对象实例的怪异者之一。

回答

在linq之前，我使用DataReader来填充我自己的自定义域对象的列表，但是在linq之前，我一直在使用L2S填充L2S实体，或者使用L2S填充域对象。

一旦我有更多的时间进行调查，我怀疑Entity Framework对象将是我最喜欢的新解决方案！

回答

我对.Net 1.1中的DataSet感到厌烦，至少他们对其进行了优化，以使它不再像大型集合那样指数级地变慢。

它始终是一个rather肿的模型，我还没有看到很多使用其大部分功能的应用程序。

SqlDataReader很好，但是我过去将其包装在一个" IEnumerable <T>"中，其中T是我的数据行的某种类型化表示。

在我看来，Linq是更好的替代品。

回答

我只是从头开始构建业务对象，几乎不再使用DataTable，尤其是不再使用DataSet，除非最初是填充业务对象。建立自己的优点是可测试性，类型安全性和智能性，可扩展性(尝试添加到DataSet中)和可读性(除非我们喜欢阅读Convert.ToDecimal(dt.Rows [i] [" blah"]。ToString()之类的东西) ))。

如果我比较聪明，那么我也会使用ORM和3rd party DI框架，但是还没有感觉到需要这些框架。我正在做很多较小的项目或者对较大项目的补充。

回答

数据集非常适合演示。

如果我们让我使用它，我将不知所措。

我使用ObservableCollection

然后我再次进入客户端应用程序空间，WPF和Silverlight。因此，通过服务传递数据集或者数据表是非常困难的。

DataReader是快速的，因为它们是结果集的前向流。

回答

几乎任何规模适中，复杂的项目都可以选择一种现代，稳定且受积极支持的ORM工具，这可能是提高生产力的唯一最大的推动力。如果得出结论，绝对，绝对，绝对必须编写自己的DAL和ORM，则可能是做错了(或者我们使用的是世界上最模糊的数据库)。

如果我们正在处理原始数据集和行，而没有执行这些操作，那么花一天时间尝试ORM，我们会惊奇地发现将列映射到字段的繁琐工作或者所有时间都花了很多时间才提高了生产力Sql命令对象以及我们曾经经历过的所有其他跳跃。

我爱我一些Subsonic，尽管对于较小规模的项目以及演示/原型，我发现Linq to Sql也非常有用。我虽然满怀热情地讨厌英孚。 ：P

回答

我一直在使用"数据传输对象"模式(我相信最初来自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。

回答

我已经在多个项目中使用类型化的数据集。它们很好地对数据库建模，在客户端上施加约束，并且通常是一种可靠的数据访问技术，尤其是在带有TableAdapters的.NET 2.0中所做的更改。

键入数据集会受到那些喜欢使用诸如"膨胀"之类的情感性词语来形容他们的人的辱骂。我会同意，我更喜欢使用一个好的O / R映射器，而不是使用DataSet。使用对象和集合而不是键入的DataTables，DataRows等"感觉"更好。但是我发现，如果由于某种原因我们不能或者不想使用O / R映射程序数据集是一个很好的可靠选择，它易于使用，将为我们带来O / R映射器90％的好处。

编辑：

这里有人建议DataReader是"快速"的选择。但是，如果使用Reflector查看DataAdapter的内部(填充DataTable的内部)，则会看到它使用了... DataReader。类型化的数据集可能比其他选项具有更大的内存占用空间，但是我还没有看到应用程序在这方面产生明显的变化。

使用最好的工具完成工作。不要根据没有事实根据的"粗俗"或者" blo肿"等情感性词语来做出决定。