一个 DataSet 应该代表多少？以订购系统为例：在显示您的订单时，我还显示了与您的订单相似的商品列表以及我们最受欢迎的商品列表。 虽然您的项目在涉及您和您过去的订单、首选供应商以及与您作为客户相关的各种其他类型的信息的关系网络中纠缠不清，但其他项目没有这些相同的关系。我用于导航代表您的一组内容的查询集不同于我用于这些其他项目列表之一的查询。
我倾向于为不同类型的关系创建不同的数据集，但随后我创建了十个单独的项目数据表，这似乎是错误的。当我实例化较大的数据集时，即使我只对一个看起来错误的小子集感兴趣，当我尝试将所有这些打包到一个数据集中时，我有一个看起来很凌乱的东西，几个项目表彼此相邻，我是很确定这是错误的。
也许我高估了数据集的关系特性，或者我只是需要克服自己，无论哪种方式我都可以使用一些指导。
【问题讨论】：
DataSet 被严重高估和过度使用。使用强类型集合（谢谢，泛型和自动属性！）。作为锦上添花，您现在甚至可以使用 LINQ 对您的自定义对象进行很酷的查询。
关于数据集与自定义对象的优秀 Esposito 文章：
http://msdn.microsoft.com/en-us/magazine/cc163751.aspx
自动属性：
http://weblogs.asp.net/dwahlin/archive/2007/12/04/c-3-0-features-automatic-properties.aspx
LINQ 与您的对象：
http://blogs.msdn.com/wriju/archive/2006/09/16/linq-custom-object-query.aspx
【讨论】：
这就是我不使用数据集的原因。如果您使用强类型数据集，您将从强类型中受益，但您需要为创建一个数据集所花费的时间付费，即使您只是使用它的一部分以及它在代码库方面的可扩展性。如果您想修改现有的行定义并修改行定义，那么这将在代码库中创建“shotgun”中断，因为添加新行的每个定义都必须修改，因为它不会再编译了。
为了避免上述情况，最明智的做法是通常放弃合理的重用。根据用途和用途定义数据集。然而，主要问题是 API 使用，您最终得到的数据集与另一个数据集相似，但由于它是不同的数据集类型，您必须将其转换为使用既痛苦又不优雅的通用 API。
这一点，加上强类型数据集让你的代码看起来很糟糕（类型声明的长度）几乎是我放弃数据集并转而使用业务对象的原因。
【讨论】：