使用 .NET 数据集的正确方法是什么？ [关闭]答案

【问题标题】：What is the proper way to use a .NET DataSet? [closed]使用 .NET 数据集的正确方法是什么？ [关闭]
【发布时间】：2012-09-22 22:58:00
【问题描述】：

我正在尝试找出使用 .NET 数据集的正确方法。您是否应该为数据库中的每个表创建一个 DataTable 并在 DataSet 中创建关系？在 DataSet 中重建整个数据库结构对我来说似乎很疯狂。

我将使用我的数据库的简化示例。假设我有一个CompanyEquipment 表。每台设备都属于一个成本中心，成本中心数据存储在CostCenter表中，并与CompanyEquipment表相关联。假设我有一个存储过程，它返回已与CostCenter 表连接的CompanyEquipment 数据，以在一个查询中返回所有信息。我可以使用存储过程来填充DataTable，但是如何将这个非规范化的结果表保存回数据库？我不知道这是否是一个好方法。我认为查询使用关联（桥）表的多对多关系将需要多个查询。例如，我有一个 EquipmentRole 表，用于存储不同的设备使用情况，还有一个 EquipmentRoleAssignment 表，其中可以为设备分配多个角色。

或者，如果我有模仿数据库的 DataTables，我必须在每个表上使用 DataAdapter.Fill() 分别查询每个表，以将相关数据放入每个 DataTable。所以我会有类似select * from CompanyEquipment where equipID = 1234 的东西，我会用它和适配器一起填充CompanyEquipment DataTable，然后我必须使用另一个查询select * from CostCenter where costCenterID = <costcenterID from the companyequipment record> 并填充CostCenter DataTable。使用这种方法，我必须访问数据库两次，并且我失去了 DBMS 执行连接的能力。

我是数据驱动应用程序的新手，所以我不熟悉工作流程；特别是我应该访问数据库多少次才能获得一种数据表示。任何帮助表示赞赏。我正在使用 C#。

【问题讨论】：

最好先创建一些类来表示您的数据，因为您希望在应用程序中使用它。依赖 DataTable 和 DataSet 确实会将您锁定在数据库的结构中，最终您会失去灵活性。此外，某些内置结构（尤其是 DataSet）在涉及序列化和/或缓存的任务时会带来额外的问题。
感谢您的意见。我实际上开始构建自己的类来以面向对象的方式表示数据。我什至开始构建自己的映射类，然后遇到了诸如将多对多关系映射为另一种域类型中的一种域类型的列表以及处理空值等问题。持久化这些对象带来了许多其他设计问题，然后我意识到我正在自己构建一个 ORM，这很愚蠢，因为我永远不会让这个应用程序在下个世纪工作。
可以转成社区wiki吗？

标签： c# .net ado.net dataset

【解决方案1】：

完全没有？自 .NET 1.0 以来，我一直没有使用 DataSet。使用 ORM，游戏结束。 DataSet 在报表应用程序之外的实际用途为零，这些应用程序允许用户完全动态地组合查询，即使在这种情况下，大多数时候也有更好的解决方案。

【讨论】：

您不知道您使用的是什么版本的 .Net，但看看“实体框架”，您应该朝着正确的方向前进。
我查看了 EF，但遇到了继承问题。数据库混合了 table-per-hierarchy 和 table-per-type 继承，EF 不支持混合继承方案。因此，假设所有设备都继承自应该是抽象的基本实体 Item，我必须将其设为非抽象并查询类型作为基本类型，而它们应该是强类型子类型。例如，如果我查询计算机，而计算机没有子类型实体，我将收到 Item 类型的对象。如果这听起来对您来说是正确的，那么也许我应该只使用 EF？我觉得这很奇怪。
@BlueChippy 对不起。使用 .Net 4. 感谢您的推荐。请查看我对 TomTom 的回复，了解我在使用 EF 时遇到的问题。也许我可以得到你的意见。如果您需要有关此问题的更多信息，请告诉我。
从未使用过 EF - 如果我需要状态跟踪，现在可能从 4.5 开始。我用 BlToolkit 做大部分工作，但我们的工作有点特别——我们使用数据库作为序列化存储，所有事务都发生在内存中。嗯，90%。

【解决方案2】：

我过去曾使用过数据集（但很久以前），根据我的经验，这是我的 0.02 美元

您的选项 1 和选项 2 都是关于如何使用数据集的有效方案。

对于检索场景：- 这取决于您如何使用数据。

例如，在您知道所有主表 + 相关表数据正在例如立即显示给用户的情况下，选项 1 可能更可取。

但是，在某个场景中，您可能会显示一个包含主表数据的表，并且仅在单击一行时才显示相关的表信息，因此最好使用选项 2，因为它可以让您获得按要求提供数据。

用于插入/更新场景

选项 2 在内存结构模仿数据库的情况下效果最佳。因此，使用适配器甚至命令构建器对象和数据行状态（插入/更新/删除），您可以轻松插入/更新/删除适当的数据，而无需太多麻烦。如果您要使用选项 1，则需要编写逻辑将其拆分并自己保存到单独的表中。

希望这是有用的。然而，就像大多数现实生活场景一样，这真的取决于

注意：我完全避免使用数据集/数据表，我有一段时间因为它们是相当重的对象，因此往往会消耗资源。如果您确实使用它们，请确保根据您的性能要求进行性能测试，以确保它们最终不会长期不适合

【讨论】：

感谢您的意见。至少我知道我离得太远了。 DataSet 不是我的第一选择，我想使用实体框架但遇到了一些问题，而且时间限制正在扼杀我的选择。我对 DataSet 的经验很少，对 EF 没有经验。所以我想我会使用DataSet，但我从来没有在这么大的项目上使用过DataSet。作为记录，如果使用选项 2，即使是 30 个表，为每个数据库表创建 DataTables 是否正常？另外，你用什么来代替 DataSets/Tables，因为就像你说的那样，DataSet 可能不是未来的最佳选择。
是的。如果您要走数据表路线，我强烈建议您使用“强类型”数据集/数据表，因此每个表都会存在不同的数据表。它只是让事情变得更容易编码和维护。我相信那里有可用的工具，如果你将它们指向你的数据库，它们会自动为你的数据表生成 xsd / 代码。对于您的第二点，我主要在我的大多数应用程序中使用 POCO。在 DAL 方面，我使用了 ORM 中的各种技术，例如 nHibernate / 使用 CodeSmith 模板自动生成 DAL 代码 / 手写 DAL
根据我的经验，当你做一些简单的事情时，使用 ORM 总是有点矫枉过正，相反，有时它可能会很痛苦，尤其是当你的对象图非常大和复杂的时候。所以，我没有那部分的灵丹妙药。我会做最适合这种情况/项目的任何事情
@reallythecrash：如果您想快速开始使用 EF4，请向上工作数据库。从数据库生成您的 EF 模型 - 然后它应该像添加对上下文（数据库）的引用和一些非常简单的读/写方法一样简单。就我个人而言，我更喜欢代码优先的 POCO，但最终往往更频繁地使用数据库，因为我经常已经有了数据库。

【解决方案3】：

我建议将 POCO 与实体框架一起使用。使用 EF，您可以使用 Entity Framework Power Tools 为现有数据库生成 POCO 类、派生的 DbContext 和 Code First 映射。这将减少您自己创建课程的努力。您现在有了可以与 EF 一起使用的类来解决您在问题中描述的问题。

【讨论】：