有人在.NET中使用类型化的DataSet吗？

Question

我曾经尝试在相对较小的生产应用程序中使用类型化的DateSet。最初它看起来是一个非常好的主意，但事实证明是不同的。对于一些基本任务来说这是相当不错的，但是只要需要更高级的东西，它就会受到限制并且失败了。幸运的是，该项目被取消了，从现在开始，我尝试坚持使用像NHibernate这样的ORM。

但我仍然想知道 - 他们是出于某种原因而创建的。也许我只是不明白如何正确使用它们？是否有人在生产系统中成功使用它们？

加了：

你能快速解释一下你是如何使用它们的吗？

我尝试将它们用作我的DAL - 它是一个Windows窗体应用程序，它会将数据从表中提取到DataSet中，然后在调用TableManager的层次更新之前对数据进行操作（不记得确切）名称）。 DataSet的每个DB的物理表都有一个表。当我不得不做一些像主/细节关系这样的事情时我就不得不一次插入一堆记录（一个主记录和几个细节记录）到几个表中，同时保持外键正确。

已添加2：

哦，如果您正在使用它们，那么您将业务逻辑放在哪里？ （验证，计算等）

Answer 1

我们一直使用类型化数据集，事实上我们将它们用作最佳实践。我们这样做的原因是在编译时捕获错误，而不是使用基于字符串的查找来查找可能在运行时引入错误的列名。

我想，与往常一样，这取决于场景以及您是否获得使用它们的任何优势。

正常行参考：

oRow["row_pk"]

在键入的数据集中，它现在变为：

oRow.row_pk

我们的数据集通常与数据库scema匹配，我们使用DataAdapters使用存储过程更新对数据库的更改。输出参数使用从数据库生成的密钥更新数据集。

显然，您需要按正确的顺序运行适配器更新，以便按正确的顺序生成所有密钥。删除父/子行时也必须小心，并确保以正确的顺序进行这些删除以防止数据库异常。

当.NET仍然是1.1时，我在ADO.NET by David Sceppa上读了一本书，这让我看到了实际可以实现的内容，并简化了我的DAL（使用类型化数据集）。有很多技术可以真正帮助改进你的代码，我强烈推荐它。

Answer 2

对我来说，创建XML文档以发送到Web服务非常有用。客户端将预期数据定义为类型化DataSet，这使得在内存中创建DataTable并获取XML表示非常简单。

现在，对于真正的数据库访问......我使用自己的DAL，我同意你的看法 - 数据集非常有限。

Answer 3

我在以下情况下使用它们： 1）写完一次我们正在进行的项目后抛弃的“1-offs”就完成了。 2）使用XML文件与其他供应商交换数据。 3）原型设计和测试，

我在输入数据集时遇到问题： 1）需要复杂的查询来过滤和保存数据。 （至少对于我来说） 2）不了解Visual Studio设计器代表我写的内容，以便我可以扩展为类型化数据集创建的派生类。

我从未遇到类型化数据集的速度问题，用户似乎对使用它们构建的应用程序感到满意。说实话，我没有对可以替换类型化数据集的不同方法进行基准测试。最后，通过使用类型化数据集，像我这样的新手程序员错过了设计时间类型检查，我不止一次保存。

问候，

调试

Answer 4

我正在使用它们。也许只是因为我没有尝试过NHibernate，但是我不能使用LINQ，因为我只限于Windows 2000，它不运行.NET 3.起初它们似乎很理想，但我发现了足够奇怪的怪癖关于他们开始让我失望。

Answer 5

如果您相信软件编写软件的好处，以及静态类型 - 软件捕获软件错误 - 以牺牲复杂性（当然），开发开销（可能）和效率（可能但可论证）的代价，它们正是您所需要的。 ） - 这是C＃和java等语言的基本前提。

然而，那不是一场完全赢得的战斗。

编辑（请求解释）：

复杂度。

使用C＃或java，最终会得到大量用于配置，类型声明，转换，类型检查和验证的代码。你自己写的一些，IDE为你写的一些。但这是开发人员负责的所有代码。主要的好处是IDE /编译器 - 指出可能的软件错误和自动完成。我可以肯定地说，没有任何一方，业界讨论代码行中的绝对数量是否值得。它至少明显违反了YAGNI。在VS中，我经常遇到由IDE编写的整个代码文件，其中包含我最终需要弄清楚的错误。我不喜欢弄清楚我没写的代码。

开发开销。

同上以上。 java是众所周知的，您需要编写和维护所有各种XML配置文件，以使应用程序能够整合在一起。 RoR的很多吸引力是“按惯例配置”，只是为了避免这种情况。

效率。

与编译语言相比，解释或JIT编译的语言非常低效的断言长期以来被认为是不言而喻的。由于更多原因而不是我有时间在这里，这个假设受到质疑;例如，一些更新，更快的JavaScript引擎。

在这个网站上搜索的显而易见的东西，以及google for，是“后期绑定”，“动态类型”，“JIT编译器”。

Answer 6

我使用它们，但不是通常意义上的。它类似于ocdecio的答案，虽然在我的情况下它是asp.net中的表示模型（没有表适配器）

“客户服务”层使用它们（作为合同的部分）用于获取或返回数据的任何方法。底层业务服务使用更传统的poco方法，客户端服务只需进行一些映射即可为给定的ui生成强类型数据集。

工具支持使新开发人员（可以跟随asp.net /学习视频加快速度）更容易使用他们需要的服务。 UI构建器还可以快速“设计”他们想要检索的新数据集，并让相关服务团队从那里开始。

Answer 7

我仍然使用它们比我希望的更多......它们肯定比无类型数据集更好，但你必须小心可以为空的值类型字段。如果您有一个可以包含空值的Int字段，则当它具有null值时它不能尝试访问该字段，否则它将引发异常。你必须先调用IsMyIntFieldNull（）来检查它是否为空。这意味着你的代码无论何时引用其中一个字段，你需要先进行检查...这很容易增加额外的额外数量码。如果类型化数据集支持这些列的可空值字段会更好，但不幸的是它们不支持。