What are the disadvantages of Typed DataSets我来自一个喜欢构建自己的世界，而不是依赖于他人构建的库和框架的世界。逃避这个世界后，我发现在Visual Studio中使用诸如Typed DataSets之类的工具既轻松又有趣。那么，除了失去灵活性之外，您还会失去什么呢？是否存在性能因素(不考虑proc与动态sql的争论)？局限性吗？ 类型化的数据集是对经典ADO断开记录集的升级。我发现它们在需要执行某些面向行的排序任务的简单情况下仍然很好用-即，您仍然希望在行，列，约束等数据库范式的上下文中工作。如果在这种情况下使用得当，那就可以了。 在某些方面其收益会减少：
通常，根据我的经验，我发现复杂的系统(例如，许多大型企业系统)最好不再使用数据集，而转向使用特定于实体域的对象模型-如何输入和输出数据这些对象中的一个(例如，使用ORM)完全是另一个话题。但是，在小型项目中，需要先对表格进行基本维护和其他一些简单操作的表格，通过数据集范式可以实现很高的生产率-尤其是与Visual Studio / .Net强大的数据绑定功能结合使用时。 我要提出的主要批评是，它们的伸缩性不好-与轻量级业务实体或DTO或LINQ to SQL相比，当您获得更多事务时，开销会降低性能。架构更改也令人头疼。对于"工业强度"体系结构，它们可能不是要走的路，从长远来看，它们会引起问题。 我仍然肯定会将它们用于快速，肮脏的PoC或简单的实用程序-使用Visual Studio中的工具，它们确实非常方便使用，并且可以完成工作。 使用类型化的数据集比未类型化的数据集提高了性能(尽管我从未发现诸如此类值得琐碎的事情带来的性能问题)。 我想说的最大的麻烦就是保持它们与您的数据库同步-我不能说VS 2008，但是以前的版本对此不提供良好的支持。每当结果集的架构发生更改时，我都会将procs实际上拖到设计器上。不好玩。 但是，您确实可以进行编译时类型检查，这很不错，例如Customer.Name而不是Dataset.Tables(0).Rows(0)(" Name")。 因此，如果您的架构是相对静态的，那么它们可能是值得的，但是否则，我不会打扰。 您还可以查看真实的ORM。 我仅短暂尝试了Typed Datasets。当我发现我的代码在生成的代码的1000行文件中破坏了大约2/3的方式时，我停了下来。 我不喜欢的另一件事是我认为我会写类似Customer.Name的代码，但是默认情况下，我似乎会得到类似CustomerDataSet.Customers [0] .Name的代码，其中Customers [0]是类型的CustomersRow。与未类型化的数据集相比，它的可读性仍然更好，但实际上并不是我正在寻找的语义。 我个人沿着ActiveRecord / NHibernate的路线前进，此后再也没有回头。 我不是打字数据集的忠实拥护者。我无法使用类型化的数据集来提高性能。它纯粹是对现有数据库对象的package。我不能考虑像employee.empName这样的访问。投射仍在package器中完成。另一个开销是大量的代码。 LOC增加。内存中有许多活动对象。没有自动更新架构。无论如何，类型化数据集除了给开发人员带来便利之外，对开发人员没有用。作为开发人员，我们没有任何权利要求舒适感：)减轻痛苦……减轻使用者的痛苦：) 类型化数据集没有错。它们并不完美，但是这是解决对象关系阻抗不匹配问题的下一步。我面临的唯一问题是对架构更改的支持不足。局部类可以提供帮助，但并非在每种情况下都可以提供帮助。 如果忽略了前面提到的所有问题，则数据集非常适合与Visual Studio一起快速拍打。我没有提到的一个问题是Visual Studio设计图面内数据集的可视可伸缩性。随着系统的发展，数据集的大小不可避免地变得笨拙。设计人员的视觉方面根本无法扩展。当数据集有超过20个左右的表时，四处滚动以尝试查找特定的表或关系确实是一个痛苦。 |
