17

我来自一个喜欢构建自己的世界而不是依赖他人构建的库和框架的世界。逃离这个世界后，我发现在 Visual Studio 中使用 Typed DataSets 等工具的乐趣和轻松。那么除了失去灵活性之外，你还失去了什么？是否有性能因素（忽略 procs 与动态 sql 的争论）？限制？

4

7 回答 7

14

到目前为止，类型化数据集是经典 ADO 断开连接记录集的升级版。我发现在需要执行一些面向行的排序任务的简单情况下，它们仍然很好用——即，您仍然希望在行、列、约束等的数据库范例的上下文中工作。如果在这种情况下明智地使用，那么你就可以了。

有几个方面他们的好处会减少：

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

一般来说，根据我的经验，我发现复杂系统（例如许多大型企业系统）最好不要使用数据集，而更多地转向可靠的领域特定对象模型——如何让数据进出这些对象（例如使用 ORM）完全是另一个话题。然而，在需要基本维护和一些其他简单操作的数据前面有一个表单的小型项目中，数据集范式可以实现很高的生产力——尤其是与 Visual Studio/.Net 强大的数据绑定功能相结合时。

于 2008-09-10T03:09:58.617 回答
10

我要扩展的主要批评是它们不能很好地扩展 - 与轻量级业务实体或 DTO 或 LINQ to SQL 相比，当您获得更多事务时，性能会因为开销而受到影响。架构更改也令人头疼。对于“工业实力”架构，它们可能不是要走的路，从长远来看它们会引起问题。

我仍然肯定会将它们用于快速而肮脏的 PoC 或简单的实用程序——考虑到 Visual Studio 中的工具，它们使用起来真的很方便，并且可以完成工作。

于 2008-09-10T02:58:17.443 回答
5

与无类型数据集相比，类型化数据集的性能得到了提高（尽管我从未发现像这样的琐碎事情值得担心的性能问题）。

我想说最大的痛苦就是让它们与您的数据库保持同步——我不能代表 VS 2008，但以前的版本并没有为此提供良好的支持。每次结果集的架构发生变化时，我都会将 procs 拖到设计器上。不好玩。

但是，你确实得到了编译时类型检查，这非常棒，比如 Customer.Name 而不是 Dataset.Tables(0).Rows(0)("Name")。

因此，如果您的架构是相对静态的，那么它们可能是值得的，但否则，我不会打扰。

您还可以查看真正的 ORM。

于 2008-09-10T02:47:32.837 回答
4

我只给了 Typed Datasets 一个很短的尝试。当我发现我的代码在 1000 多行的生成代码文件中中断了大约 2/3 时，我停下了脚步。

我不喜欢的另一件事是我认为我可以编写像 Customer.Name 这样的代码，但默认情况下我似乎得到像 CustomerDataSet.Customers[0].Name 这样的代码，其中 Customers[0] 的类型是 CustomersRow . 仍然比无类型数据集更好阅读，但不是我正在寻找的语义。

就我个人而言，我走上了 ActiveRecord/NHibernate 的路线，从那以后就再也没有回头。

于 2008-09-10T02:56:55.280 回答
2

类型化的数据集没有任何问题。它们并不完美，但它是解决对象关系阻抗失配问题的下一步。我面临的唯一问题是对架构更改的支持较弱。部分课程可以提供帮助，但并非在所有情况下都可以。

于 2008-09-10T02:51:14.810 回答
2

我不是类型化数据集的忠实粉丝。我无法使用类型化数据集来提高性能。它纯粹是对现有数据库对象的包装。我不能考虑像employee.empName这样的访问。铸造仍然在包装中完成。另一个开销是大量代码。LOC 增加。内存中有这么多活动对象。没有自动更新架构。无论如何，类型化的数据集对开发人员来说都是没有用的，除了它提供的舒适性。作为开发人员，我们没有任何权利要求舒适 :) 忍受痛苦...摆脱用户的痛苦 :)

于 2009-12-13T14:21:41.927 回答
1

如果忽略前面提到的所有问题，数据集非常适合与 Visual Studio 一起快速处理某些内容。我没有看到提到的一个问题是 Visual Studio 设计界面中数据集的视觉可伸缩性。随着系统的增长，数据集的大小不可避免地变得笨重。设计师的视觉方面根本无法缩放。当数据集有超过 20 个左右的表时，滚动试图找到特定的表或关系真的很痛苦。

于 2009-04-10T23:10:43.550 回答