为什么我们仍然在.NET中使用DataSet？

DataSet是.NET 1.0中最重要的东西之一,甚至现在使用.NET 3.5时我仍然发现自己不得不使用它们....特别是当我必须调用存储过程,它返回一个数据集然后我最终拥有手动转换为对象以使其更易于使用.

我从来没有真正喜欢过DataSet,并且发现它们很难使用...因此我倾向于将我对它们的了解保持在最低限度(可能是非常糟糕的事情!).我也喜欢将它们快速转换为对象或对象列表,以便我可以在代码中轻松操作它们.

DataSet是否按日期传递使用？随着像NHibernate这样的O/R映射器的出现,我想知道DataSet会不会消失或者还有它们的位置？目前,我是否应该留出时间重新访问DataSet并学习如何正确使用它们或者100%完成O/R映射器并完全抛弃DataSet.

DataSet是否提供NHibernate和LINQ等技术无法提供的功能？如果没有,为什么我们仍然使用它们呢？

无论好坏,答案都是简单的.当2.0 Framework出现并且TableAdapter被包含在这个过程中时,获得基本的CRUD类型应用程序,甚至是显示数据的首页,滚动变得非常容易.只需连接到您的服务器,将您的表拖过,结构就位,包括外部/主要/唯一键引用.需要对此数据执行更新？使用向导,指定现有过程,或让向导为您生成特殊/存储过程.

而且你已经完成了,将它连接到GridView并且你可以快速做很多事情:求助,重新查询,在断开连接时编辑多个记录,以及单个或批量更新.当你在想要快速完成的项目上工作时,这种便利很难理解.如果你需要的话,那么使用这种本机"DataTable"格式的东西对于XML恶作剧来说变得很方便,因为DataSet模型在很多东西中使用了XML.

我承认我还没有检查出最新版本的ORM,我不确定是否有一个LINQ向导可以在几次点击后完成这么多工作.而且大多数人在适应新技术方面都有点慢,所以很容易看出它是如何被大量使用的.

看到新的动态数据服务站点/项目是基于LINQ to SQL或LINQ to EF构建的,我认为潮流可能最终会转变为更新的模型.

我认为数据集的最大问题是它们基本上鼓励你在内存中创建一个dbms.我喜欢Linq /实体满足您的数据需求的方式,他们依靠标准的.Net集合类和泛型来工作.

也就是说,我不会忘记能够动态读取无类型数据并在内存中应用关系等的能力,这仍然是非常强大的功能,具体取决于您的情况.

我从来没有正确使用过DataSet(连接到SQL Server),但它对于特定需求一次非常有用.我发现DataSet和DataView是用于实现数据/ BLL层的非常方便和功能的基类,直到我可以把一些经过深思熟虑的东西放到适当位置.如果没有别的,你应该注意到很多功能.