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

问题描述

我来自一个喜欢自己构建而不是依赖他人构建的库和框架的世界.逃离这个世界后，我发现在 Visual Studio 中使用 Typed DataSets 等工具的乐趣和轻松.那么除了失去灵活性之外，你还失去了什么?是否有性能因素(忽略 procs 与动态 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 断开连接记录集的升级版.我发现它们仍然很适合在需要执行一些面向行的排序任务的简单情况下使用——即，您仍然希望在行、列、约束等的数据库范例的上下文中工作.如果在这种情况下明智地使用，那么你就可以了.

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:

• 我认为这里提出的同步问题肯定是个问题，特别是如果您已经自定义它们或将它们用作基类.
• 根据数据集中数据表的数量，它们可能会变得非常胖.我的意思是多表数据集通常呈现数据的关系视图.除了内存占用之外，随之而来的是键的定义和潜在的其他约束.同样，如果这正是您所需要的，但如果您需要一次快速遍历数据，那么带有数据读取器的高效循环可能是更好的选择.
• 由于其复杂的定义和潜在的大小，也不建议在远程情况下使用它们.
• 最后，当您开始意识到您需要处理与您的问题领域相关的对象中的数据时，使用这些对象的障碍多于好处.您经常发现自己将字段移入和移出集合中的行表，并关注表和行的状态.您开始意识到，他们使用 OO 语言来更容易地表示现实世界的问题域对象，而使用表、行和列并不真正适合这种思维方式.

• 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.

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