【发布时间】：2010-09-08 09:00:32
【问题描述】：
我来自一个喜欢自己构建而不是依赖他人构建的库和框架的世界。逃离这个世界后，我发现在 Visual Studio 中使用 Typed DataSets 等工具的乐趣和轻松。那么除了失去灵活性之外，你还失去了什么？是否有性能因素（忽略 procs 与动态 sql 的争论）？限制？
【问题讨论】：
标签： .net ado.net data-access-layer dataset
【发布时间】：2010-09-08 09:00:32
【问题描述】：
我不是类型化数据集的忠实粉丝。我无法使用类型化数据集来提高性能。它纯粹是对现有数据库对象的包装。我不能考虑像 employee.empName 这样的访问。铸造仍然在包装中完成。另一个开销是大量代码。 LOC 增加。内存中有这么多活动对象。没有自动更新架构。无论如何，类型化的数据集对开发人员来说都是没有用的，除了它提供的舒适性。作为开发人员，我们没有任何权利要求舒适 :) 忍受痛苦...摆脱用户的痛苦 :)
【讨论】：
如果忽略前面提到的所有问题，数据集非常适合与 Visual Studio 一起快速处理某些内容。我没有看到提到的一个问题是 Visual Studio 设计界面中数据集的视觉可伸缩性。随着系统的增长，数据集的大小不可避免地变得笨重。设计师的视觉方面根本无法缩放。当数据集有超过 20 个表时，滚动查找特定表或关系真的很痛苦。
【讨论】：
类型化的数据集没有任何问题。它们并不完美，但它是解决对象关系阻抗失配问题的下一步。我面临的唯一问题是对架构更改的支持较弱。部分课程可以提供帮助，但并非在所有情况下都可以。
【讨论】：
到目前为止，类型化数据集是经典 ADO 断开连接记录集的升级版。我发现它们仍然很适合在需要执行一些面向行的排序任务的简单情况下使用——即，您仍然希望在行、列、约束等的数据库范例的上下文中工作。如果在这种情况下明智地使用，那么你就可以了。
它们的好处在以下几个方面会减弱：
- 我认为这里提出的同步问题肯定是个问题，尤其是如果您已经定制了它们或将它们用作基类。
- 根据数据集中数据表的数量，它们可能会变得非常胖。我的意思是多表数据集通常呈现数据的关系视图。除了内存占用之外，随之而来的是键的定义和潜在的其他约束。同样，如果这正是您所需要的，但如果您需要一次快速遍历数据，那么带有数据读取器的高效循环可能是更好的选择。
- 由于它们的复杂定义和潜在大小，也不建议在远程情况下使用它们。
- 最后，当您开始意识到您需要处理与您的问题域相关的对象中的数据时，使用这些对象的障碍多于好处。您经常发现自己将字段移入和移出集合中的行表，并关注表和行的状态。您开始意识到，他们使用 OO 语言来更容易地表示现实世界的问题域对象，而使用表、行和列并不真正适合这种思维方式。
一般来说，根据我的经验，我发现复杂系统（例如许多大型企业系统）最好不要使用数据集，而更多地转向可靠的特定领域对象模型——如何输入和输出数据这些对象（例如使用 ORM）完全是另一个话题。然而，在需要基本维护和一些其他简单操作的数据前面有一个表单的小型项目中，数据集范式可以实现很高的生产力——尤其是与 Visual Studio/.Net 强大的数据绑定功能相结合时。
【讨论】：
-
就我个人而言，我认为你的最后一个要点是关键：'他们制作了 OO 语言，以便更容易地表示 [a] 现实世界的问题域'。公平地说，您的第一点已经随着部分类的引入而略微减轻，允许每次刷新数据库时不会被吹走的表和行自定义。不过，我只会在性能被视为“硬件问题”的最简单的富客户端应用程序中使用它们。
我要扩展的主要批评是它们不能很好地扩展 - 与轻量级业务实体或 DTO 或 LINQ to SQL 相比，当您获得更多事务时，性能会因为开销而受到影响。架构更改也令人头疼。对于“工业实力”架构，它们可能不是要走的路，从长远来看它们会引起问题。
我仍然肯定会将它们用于快速而肮脏的 PoC 或简单的实用程序——考虑到 Visual Studio 中的工具，它们使用起来真的很方便，并且可以完成工作。
【讨论】：
我只对 Typed Datasets 做了很短的尝试。当我发现我的代码在 1000 多行的生成代码文件中中断了大约 2/3 时，我停下了脚步。
我不喜欢的另一件事是我认为我可以编写像 Customer.Name 这样的代码，但默认情况下我似乎得到像 CustomerDataSet.Customers[0].Name 这样的代码，其中 Customers[0] 是客户行类型。仍然比无类型数据集更易于阅读，但不是我正在寻找的语义。
我个人是沿着 ActiveRecord/NHibernate 的路线走的，从那以后就再也没有回头。
【讨论】：
类型化数据集的性能优于非类型化数据集（尽管我从未发现值得担心的微不足道的性能问题）。
我想说最大的痛苦就是让它们与您的数据库保持同步——我不能代表 VS 2008，但以前的版本并没有为此提供良好的支持。每次结果集的架构更改时，我都会将 procs 拖到设计器上。不好玩。
但是，您确实可以进行编译时类型检查，这非常棒，例如 Customer.Name 而不是 Dataset.Tables(0).Rows(0)("Name")。
所以，如果您的架构是相对静态的，那么它们可能是值得的，否则，我不会打扰。
你也可以研究一个真正的 ORM。
【讨论】：