我来自一个喜欢构建自己的世界，而不是依赖他人构建的库和框架。逃离这个世界后，我发现了在 Visual Studio 中使用类型化数据集等工具的乐趣和轻松。那么除了失去灵活性之外，你还失去了什么？是否存在性能因素（忽略 procs 与动态 sql 的争论）？限制？
到目前为止，类型化数据集是经典 ADO 断开连接记录集领域的升级。我发现它们仍然适合在需要执行某种面向行的排序任务的简单情况下使用，即您仍然希望在行、列、约束等数据库范例的上下文中工作。如果在这种情况下明智地使用，那就没问题。
它们的好处在一些领域会减弱：
- 我认为这里提出的同步问题肯定是一个问题，特别是如果您已经自定义它们或将它们用作基类。
- 根据数据集中数据表的数量，它们可能会变得相当多fat。我的意思是，多表数据集通常呈现数据的关系视图。除了内存占用之外，随之而来的是键的定义和潜在的其他约束。同样，如果这正是您所需要的，但如果您需要一次快速遍历数据，那么使用数据读取器的高效循环可能是更好的选择。
- 由于其复杂的定义和潜在的大小，在远程情况下使用它们也是不明智的。
- 最后，当您开始意识到需要使用与问题域相关的对象中的数据时，它们的使用更多地成为障碍而不是好处。您经常发现自己将字段移入和移出集合中的行表，并关心表和行的状态。您开始意识到，他们创建 OO 语言是为了更容易地表示现实世界的问题域对象，而使用表、行和列并不真正适合这种思维方式。
一般来说，根据我的经验，我发现复杂的系统（例如许多大型企业系统）最好远离数据集的使用，而更多地转向可靠的领域特定对象模型——如何将数据传入和传出这些对象（例如使用 ORM）完全是另一个话题。然而，在小型项目中，数据前面有一个表单，需要基本维护和一些其他简单的操作，使用数据集范例可以实现巨大的生产力——尤其是与 Visual Studio/.Net 强大的数据绑定功能结合使用时。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
