我来自一个有利于构建自己的世界而不是依赖其他人构建的库和框架.在逃离这个世界之后,我发现在Visual Studio中使用Typed DataSet等工具的快乐和轻松.除了失去灵活性,你还会失去什么？是否有性能因素(无视procs与动态sql争论)？限制？
到目前为止,类型化数据集是从经典ADO断开连接的记录集的世界升级的.我发现它们仍然很适合在需要执行面向行的排序任务的简单情况下使用 - 即您仍然希望在行,列,约束等数据库范例的上下文中工作.如果在这种情况下明智地使用,那么你没关系.
有些领域的收益会减少:
我认为这里提出的同步问题肯定是一个问题,特别是如果你已经去了并定制它们或将它们用作基类.
根据数据集中数据表的数量,它们可能变得非常胖.我的意思是,在多表数据集通常呈现数据的关系视图的意义上.除了内存占用之外,随之而来的是键的定义和潜在的其他约束.再说一次,如果这是你需要的,但是如果你需要快速遍历数据,那么使用数据阅读器的有效循环可能是更好的选择.
由于它们的复杂定义和潜在的大小,在远程处理情况下使用它们也是不明智的.
最后,当您开始意识到需要在与您的问题域相关的对象中处理数据时,它们的使用变得更具障碍而不是利益.你不断发现自己在集合中的行表中移动字段,并关注表格和行的状态.您开始意识到他们使用OO语言来更容易地表示现实世界的问题域对象,并且使用表,行和列并不真正适合这种思维方式.
根据我的经验,我发现复杂的系统(例如许多大型企业系统)最好不要使用数据集,而是更多地转向固体领域特定的对象模型 - 如何将数据输入和输出这些对象(例如使用ORM)是另一个话题.但是,在需要基本维护和其他一些简单操作的数据前面打了一个表单的小型项目中,使用数据集范例可以实现很高的生产率 - 特别是当与Visual Studio/.Net强大的数据绑定功能结合使用时.
我要扩展的主要批评是它们不能很好地扩展 - 与轻量级业务实体或DTO或LINQ to SQL相比,当你获得更多的事务时,性能会因为开销而受到影响.架构变化也令人头疼.对于"工业强度"架构而言,它们可能不是可行的方式,从长远来看它们会引发问题.
我仍然肯定会将它们用于快速和脏的PoC或简单的实用程序 - 它们非常方便使用Visual Studio中的工具,并完成工作.
使用非类型化数据集的类型化数据集可以提高性能(尽管我从未发现过类似于值得担心的琐碎事情的性能问题).
我说最大的痛苦就是让它们与你的数据库保持同步 - 我不能代表VS 2008,但之前的版本并没有为此提供良好的支持.每次结果集的架构发生变化时,我都会将procs拖到设计器上.不好玩.
但是,你确实得到了编译时类型检查,这很好,比如Customer.Name而不是Dataset.Tables(0).Rows(0)("Name").
所以,如果你的架构是相对静态的,它们可能是值得的,但除此之外,我不会打扰.
您还可以查看真正的ORM.
京公网安备 11010802040832号 | 京ICP备19059560号-6 