什么是类型化的DataSet的缺点 [英] What are the disadvantages of Typed DataSets

问题描述

我来自一个有利于建立自己的，而不是依赖于图书馆和其他人建立框架的世界。逃离这个世界后，我找到了快乐，轻松使用这些工具Visual Studio中强类型DataSet的。因此，除了灵活的损失你还有什么损失呢？是否有性能的因素（不考虑特效VS动态sql的争论）？限制？

I come from a world that favors building your own rather than rely on libraries and frameworks built by others. After escaping this world I have found the joy, and ease, of using such tools as Typed DataSets within Visual Studio. So besides the loss of flexibility what else do you lose? Are there performance factors (disregarding the procs vs dynamic sql debate)? Limitations?

推荐答案

类型数据集是迄今从经典的ADO连接记录世界的升级。我发现，他们仍然很好用简单的情况下使用，你需要进行某种形式的任务，这就是行导向 - 即你还是要在行，列，约束等的数据库模式的情况下工作。如果在这种情况下使用得当，那么你就OK。

Typed datasets are by far an upgrade from the world of classic ADO disconnected recordsets. I have found that they are still nice to use in simple situations where you need to perform some sort task that's row oriented -- i.e. you still want to work in the context of a database paradigm of rows, columns, constraints and the like. If used wisely in that context, then you're OK.

有几个地方的利益减少：

There are a few areas where their benefits diminish:

• 我想长大这里已经是同步的问题肯定是出了问题，特别是如果你已经走了，并定制他们或用它们作为基类。
• 根据在数据集数据表的数目，就可以成为相当的脂肪的。我的意思是在这个意义上，多表的数据集通常为present数据的关系视图。随之而来也有同感，除了在内存占用，是关键和潜在的其他限制的定义。同样，如果这就是你需要伟大的，但如果你需要快速遍历数据，一时间，然后一个有效的循环和数据读取器可能是一个更好的候选人。
• 在其复杂的定义和潜在规模，将它们用在远程情况下，由于是不明智的也是如此。
• 最后，当你开始意识到你需要你的数据一道，是有关您的问题域的对象，它们的使用变得更加阻碍而不是益处。你不断地发现自己移动领域和退出集合中的行的表，并与表和行的状态有关吧。你开始意识到，他们提出面向对象的语言，使其更容易重新present现实世界的问题领域对象和用表，行和列的工作并没有真正融入思维方式。

• I think the synchronization issues brought up here already are definitely a problem, especially if you've gone and customized them or used them as a base class.
• Depending on the number of data tables in the dataset, they can become quite fat. I mean this in the sense that multi-table datasets typically present a relational view of data. What comes along with that, besides the in-memory footprint, are definition of keys and potentially other constraints. Again, if that's what you need great, but if you need to traverse data quickly, one time, then an efficient loop with a data reader might be a better candidate.
• Because of their complex definition and potential size, using them in remoting situations is ill advised as well.
• Finally, when you start realizing you need to work with your data in objects that are relevant to your problem domain, their use becomes more of a hindrance than a benefit. You constantly find yourself moving fields in and out of rows tables in the set and concerning yourself with the state of the tables and rows. You begin to realize that they made OO languages to make it easier to represent real-world problem domain objects and that working with tables, rows and columns doesn't really fit into that way of thinking.

一般来说，在我的经验，我发现，复杂的系统（如许多大型企业系统），最好还是从使用的数据集和更多的逐渐远离迈出了坚实的特定领域对象模型 - 你如何让你的数据进出这些对象（使用ORM的为例）是对话的另一个话题完全。然而，在小项目中有掴在需要基本的维护和其他一些简单的操作数据前的形式，极大的生产力，可以来达到的与数据集中模式 - 加上与Visual Studio / .NET的强大的数据绑定功能时尤其如此。

Generally in my experience, I am finding that complex systems (e.g. many large enterprise systems) are better off moving away from the use of datasets and more towards a solid domain specific object model -- how you get your data in and out of those objects (using ORM's for example) is another topic of conversation altogether. However, in small projects where there's a form slapped in front of data that needs to basic maintenance and some other simple operations, great productivity can be acheived with the dataset paradigm -- especially when coupled with Visual Studio/.Net's powerful databinding features.

这篇关于什么是类型化的DataSet的缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！