我来自一个有利于建立自己的世界,而不是依赖其他人建立的图书馆和框架。在逃离这个世界之后,我发现在Visual Studio中使用Typed DataSet等工具的快乐和轻松。除了失去灵活性,你还会失去什么?是否存在性能因素(无视procs与动态sql争论)?限制?
答案 0 :(得分:14)
类型化数据集是迄今为止从经典ADO断开连接的记录集的世界升级的。我发现它们仍然很适合在需要执行面向行的排序任务的简单情况下使用 - 即您仍然希望在行,列,约束等数据库范例的上下文中工作。如果在这种情况下明智地使用,那么你没事。
有一些领域的好处减少了:
一般来说,根据我的经验,我发现复杂的系统(例如许多大型企业系统)最好不要使用数据集,而是更多地转向固定的域特定对象模型 - 如何将数据输入和输出这些对象(例如使用ORM)是另一个对话主题。但是,在需要基本维护和其他一些简单操作的数据前面打了一个表单的小型项目中,使用数据集范例可以实现很高的生产率 - 特别是当与Visual Studio / .Net强大的数据绑定功能结合使用时。
答案 1 :(得分:10)
我要扩展的主要批评是它们不能很好地扩展 - 与轻量级业务实体或DTO或LINQ to SQL相比,当你获得更多的事务时,性能会因为开销而受到影响。架构变化也令人头疼。对于“工业强度”架构而言,它们可能不是可行的方式,从长远来看它们会引发问题。
我仍然肯定会将它们用于快速和脏的PoC或简单的实用程序 - 它们非常方便使用Visual Studio中的工具,并完成工作。
答案 2 :(得分:5)
使用非类型化数据集的类型化数据集可以提高性能(尽管我从来没有发现过于值得担心的琐碎事情的性能问题)。
我认为最大的痛苦就是让它们与你的数据库保持同步 - 我不能代表VS 2008,但之前的版本并没有为此提供良好的支持。每次结果集的架构发生变化时,我都会将procs拖到设计器上。不好玩。
但是,你确实得到了编译时类型检查,这很好,比如Customer.Name而不是Dataset.Tables(0).Rows(0)(“Name”)。
因此,如果您的架构相对静态,它们可能是值得的,但除此之外,我不会打扰。
您还可以查看真实的ORM。
答案 3 :(得分:4)
我只给了Typed Datasets很短的尝试。当我发现我的代码在生成代码的1000多行文件中断了大约2/3时,我就停止了。
我不喜欢的另一件事是我以为我会编写像Customer.Name这样的代码,但默认情况下我似乎得到了像CustomerDataSet.Customers [0] .Name这样的代码,其中Customers [0]是类型为CustomersRow。读取比无类型数据集更好,但实际上并不是我所寻找的语义。
就我个人而言,我沿着ActiveRecord / NHibernate的路线走了一段路,从那时起就没有回头了。
答案 4 :(得分:2)
键入的数据集没有任何问题。它们并非不完美,但它是解决物体关系阻抗不匹配问题的下一步。我遇到的唯一问题是对架构更改的支持不足。部分类可以帮助但不是在每种情况下都可以。
答案 5 :(得分:2)
我不是打字数据集的忠实粉丝。我无法使用类型化数据集来提高性能。它纯粹是现有数据库对象的包装器。我无法像 employee.empName 那样考虑访问权限。仍然在包装器中完成了转换。另一个开销是巨大的代码块。 LOC增加了。内存中有如此多的活动对象。没有自动更新架构。在任何方面,类型化数据集对开发人员都没有用,除了它给出的舒适性。作为开发者,我们没有任何权利要求舒适:)带着痛苦......消除用户的痛苦:))
答案 6 :(得分:1)
如果忽略前面提到的所有问题,数据集很适合与visual studio一起快速打包。我没有看到的一个问题是Visual Studio设计界面内数据集的可视化可伸缩性。随着系统的发展,数据集的大小不可避免地变得难以处理。设计师的视觉方面根本无法扩展。当数据集有超过20个左右的表时,滚动尝试查找特定的表或关系是一件非常痛苦的事。