Effective C# 原则41：选择DataSet而不是自定义的数据结构

核心提示：因为两个原则，把DataSet的名声搞的不好，Effective C# 原则41：选择DataSet而不是自定义的数据结构，首先就是使用XML序列化的DataSet与其它的非.Net代码进行交互时不方便，如果在Web服务的API中使用DataSet时，我们还真想要一个类型化的解决方法，那就让我们来试着写一个DataSe

因为两个原则，把DataSet的名声搞的不好。首先就是使用XML序列化的DataSet与其它的非.Net代码进行交互时不方便。如果在Web服务的API中使用DataSet时，在与其它没有使用.Net框架的系统进行交互时会相当困难。其次，它是一个很一般的容器。你可以通过欺骗.Net框架里的一些安全类型来错误DataSet。但在现代软件系统中，DataSet还可以解决很多常规的问题。如果你明白它的优势，避免它的缺点，你就可以扩展这个类型了。

DataSet类设计出来是为了离线使用一些存储在相关数据库里的数据。你已经知道它是用来存储DataTable的，而DataTable就是一个与数据库里的结构在行和列上进行匹配的内存表。或许你已经看到过一些关于DataSet支持在内部的表中建立关系的例子。甚至还有可能，你已经见过在DataSet里验证它所包含的数据，进行数据约束的例子。

但不仅仅是这些，DataSet还支持AcceptChanges 和RejectChanges 方法来进行事务处理，而且它们可以做为DiffGrams存储，也就是包含曾经修改过的数据。多个DataSet还可以通过合并成为一个常规的存储库。DataSet还支持视图，这就是说你可以通过标准的查询来检测数据里的部份内容。而且视图是可以建立在多个表上的。

然而，有些人想开发自己的存储结构，而不用DataSet。因DataSet是一个太一般的容器，这会在性能上有所损失。一个DataSet并不是一个强类型的存储容器，其实存储在里面的对象是一个字典。而且在里的表中的列也是字典。存储在里的元素都是以System.Object的引用形式存在。这使得我们要这样写代码：

int val = ( int )MyDataSet.Tables[ "table1" ].
　Rows[ 0 ][ "total" ];

以C#强类型的观点来看，这样的结构是很麻烦的。如果你错误使用table1 或者total的类型，你就会得到一个运行时错误。访问里面的数据元素要进行强制转化。而这样的麻烦事情是与你访问里面的元素的次数成正比的，与其这样，我们还真想要一个类型化的解决方法。那就让我们来试着写一个DataSet吧，基于这一点，我们想要的是：