一个DataSet应该代表多少？以订购系统为例：在显示订单时，我还显示了与其中一个相似的商品的列表以及我们最受欢迎的商品的列表。
尽管项目在涉及我们和过去订单，首选供应商以及与我们作为客户的其他各种信息的关系网中纠结在一起，但其他项目却没有这些相同的关系。我用来浏览代表东西的查询集与我用于这些其他项目列表之一的查询不同。

我倾向于为不同类型的关系创建不同的数据集，但是随后我创建了十个单独的数据表，这似乎是错误的。当我实例化较大的DataSet时，即使我只对似乎是错误的一小部分子集感兴趣，当我尝试将所有这些打包到一个DataSet中时，我的外观看起来很杂乱，几个项目表彼此相邻，很确定这是错误的。

也许我高估了数据集的关系功能，或者我只是想克服自己，无论哪种方式我都可以使用一些指导。

解决方案

回答

DataSet被大大高估和过度使用。使用强类型的集合(谢谢我们，泛型和自动属性！)。锦上添花，我们现在甚至可以使用LINQ对自定义对象进行酷查询。

关于数据集与自定义对象的良好Esposito文章：

http://msdn.microsoft.com/zh-CN/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

回答

这就是为什么我不使用数据集的原因。如果我们使用强类型的数据集，则可以从强类型中受益，但是即使我们只是使用它的一部分，也要根据代码库的可扩展性来支付创建时间，但这要付出代价。如果要修改一个现有行，然后修改行定义，则会在代码库中创建""弹枪"中断，因为添加新行的每个定义都将不得不修改，因为它将不再编译。

为了避免上述情况，最明智的方法是通常放弃明智的重用。根据用途和用途定义数据集。但是，与此相关的主要问题是API的使用，最终会得到与另一个数据集相似的数据集，但是由于它是不同的数据集类型，因此我们必须将其转换为使用既痛苦又不佳的通用API。

这，再加上强类型数据集使代码看起来糟透了(类型声明的长度)，这实际上是我放弃数据集而改用业务对象的原因。