2009-01-04 39 views
4

我曾尝试在相对较小的生产应用程序中使用键入的DateSets。最初它看起来像一个不错的主意,但结果却不一样。对于一些基本的任务来说,这很不错,但是一旦需要更高级的东西,就会受到限制,并且失败了。幸运的是该项目被取消了,从现在开始,我尝试坚持一个像NHibernate一样的适当的ORM。有没有人在.NET中使用类型化的数据集?

但我仍然怀疑 - 它们是由于某种原因而创建的。也许我只是不明白如何正确使用它们?有人在那里成功地在生产系统中使用它们吗?

补充:

你能不能也赶紧解释你是如何使用他们?

我试图使用它们作为我的DAL - 它是一个Windows窗体应用程序,并且它会从表中将数据从表中获取到DataSet中,然后在调用TableManager的层次更新事物之前使用数据进行处理(不记得确切的名字)。 DataSet对每个数据库的物理表都有一个表。当我不得不做一些像master/details关系那样的事情时,问题就开始了,我必须一次插入一堆记录(一个主记录和多个详细记录)到几个表中,同时保持外键正确。

新增2:

哦,如果你使用的是他们,你在哪里把你的业务逻辑呢? (验证,计算等)

回答

3

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

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

2

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

+0

如果您仅限于Windows 2K和.Net 2.0,那么您应该认真看待SubSonic 2.1 - 在类型化数据集的痛苦之后,我在很多应用程序中使用了它,并且从不回头。它可以正常工作.Net 2.0 – 2009-01-04 19:48:13

4

我们始终使用键入的数据集,实际上我们将它们用作最佳实践。我们这样做的原因是在编译时捕获错误,而不是使用基于字符串的查找列名,这可能会在运行时引入错误。

我想,一如既往,这取决于场景以及您是否获得使用它们的优势。

的标准行参考:

oRow["row_pk"]

在类型化数据集,现在变成了:

oRow.row_pk

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

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

返回.NET时仍然是1.1我读了一本关于ADO.NET by David Sceppa的书,这开启了我的视野,让我可以真正体会到什么,并简化了我的DAL(使用键入的数据集)。那里有很多技术可以真正帮助改进你的代码,我强烈推荐它。

+1

嗯...不是他们在发动机罩下做的吗? – 2009-01-04 00:56:41

+0

他们这样做,但类型转换代码是从数据库模式生成的,不太可能包含错误。 – recursive 2009-01-04 00:58:05

2

如果您相信软件编写软件的好处,以及静态类型 - 软件捕捉软件错误 - 的代价,那么它们正是您所需要的,但代价是复杂性(当然),开发开销(可能)和效率(可能但是可争辩的) - 这是C#和java等语言的基本前提。

然而,这并不是一场完全获胜的战役。

编辑(请求解释):

复杂性。

使用C#或java,你最终会得到很多配置,类型声明,转换,类型检查和验证的代码。其中一些是你自己写的,一些IDE是为你写的。但这是开发者负责的所有代码。主要的好处是IDE /编译器 - 指出可能的软件错误和自动完成。我可以放心地说,没有采取任何一方的行业讨论,是否有代码量的庞大数量是值得的。这至少明显违反了YAGNI。在VS中,我通常会遇到由IDE编写的整个代码文件,它有一些缺陷,我最终需要弄清楚。我不喜欢搞清楚我没有写的代码。

开发开销。

同上。而且java对于所有需要编写和维护的各种XML配置文件而言都是众所周知的,它们可以使应用程序组合在一起。 RoR的很大吸引力是“按照惯例配置”,只是为了避免这种情况。

效率。

与编译语言相比,解释或JIT编译语言的效率非常低下的断言早已被接受为不言自明。由于比我有时间在这里有更多的原因,这个假设正受到质疑;例如通过一些更新,更快的JavaScript引擎。

在这个网站上搜索的明显的东西,谷歌的,是“后期绑定”,“动态类型”,“JIT编译器”。

2

我使用它们,但不是通常意义上的。这是类似于ocdecio的答案,但在我的情况下,它在asp.net作为一个演示模型(不包括表适配器)

的“客户服务”层使用它们(作为部分合同)的任何方法,该方法或返回数据。基础业务服务使用更传统的poco方法,客户端服务只是做一些映射来为给定的UI生成强类型的数据集。

工具支持使新开发人员(他们可以按照asp.net/learn视频来加快速度)使用他们所需的服务,从而更容易。 UI构建者还可以快速“设计”他们想要检索的一组新数据,并让相关服务团队从那里开始。

3

我在以下情况下使用它们: 1)编写一次性项目,一旦我们正在处理的项目完成,就会退出。 2)使用XML文件与其他供应商交换数据。 3)原型和测试,

我有类型数据集时出现问题: 1)需要复杂的查询来过滤和保存数据。 (至少对我而言) 2)不知道Visual Studio设计师为我写的东西是否足够,以便可以扩展为类型化数据集创建的派生类。

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

问候,

调试

1

我仍然可以使用他们比我更希望我所做的......他们肯定比非类型化数据集更好,但你必须要小心空值类型的字段。如果您有一个可以包含空值的Int字段,那么您无法在字段为null时尝试访问该字段,否则会引发异常。你必须首先调用IsMyIntFieldNull()来检查它是否为/不是空的。这意味着你的代码引用了这些字段之一,你需要首先检查这个字段......这很容易加上大量额外的码。如果输入的数据集支持这些列的可为空值的字段会更好,但不幸的是他们不支持。

相关问题