刚才看了Truly的关于Typed Dataset的测试的一篇文章，一时兴起，想换个角度说说Typed Dataset。
先申明，本文只代表本人愚见，如有不同看法，请直接反驳。
什么是Typed Dataset
这个问题不知道有没有必要提，其实早先我对Typed Dataset的认识也是比较模棱两可的，用我的话讲就是“用实践来说话”。一般意义上讲，VS.Net提供了创建Typed Dataset的方法，虽然生成的代码很庞大，但是却很够用，而且估计很多人谈的Typed DataSet也就是指这个。
看过Duwamish7源码的人应该都知道，它的DAL里的实体就是以Dataset的形式呈现的，我早先还自以为是的给它冠以“强类型”Dataset的称谓，但是，严格意义上讲这种Dataset不能称为Typed Dataset。
用Truly的话来解释什么是Typed Dataset：
我的理解，Typed Dataset应该是
1. 继承于DataSet类的一个类；
2. 提供对其所存储数据的架构的基本属性的直接访问；
3. 本身应该包含次级容器的对象定义以及直接访问支持（即DataTable & DataRow）；
4. 可以让开发人员更高效的编写数据访问的代码。
个人认为，上面的最后一点是Typed Dataset的关键，虽然truly关注了它与普通dataset的性能差异，但是我还是觉得Typed Dataset很大程度上simplified the task of data navigation and operation。
Typed Dataset的应用
本来不想就这个东西的应用做讨论，因为说实话我觉得我还没有资格，我对Typed Dataset的应用还不多，一方面也是因为我觉得一个这样的类对我而言显得很臃肿，不说生成的代码，就它占用的内存就让我一定程度上只把他作为过度性的数据存储对象，更多时候我的实体对象类还是用自己写的小工具来生成。
但是就我的了解，M$推荐开发人员使用Dataset/Typed Dataset。确实，在大家都在大肆讨论ORM的时候，Dataset这个东西提供了一个简便的亦或是是轻量级（我个人这么认为）的O/R Mapping的机制，而强类型的Dataset更是更大限度的发挥了这方面的长处。
其实要说强类型的Dataset的应用，首先就先会想到普通的Dataset的一些应用，我见过一些朋友十分依赖Dataset，把它作为处理/存储数据的一个金钥匙，甚至毫无“保留”的作为保存状态的方式（存在Session中等等）。其实很大程度上变成了“滥用”。
Duwamish对Dataset的应用应该是做的很恰当的，虽然我说它的Dataset不算纯粹的Typed Dataset，但是，它的确具备了作为强类型的部分基本条件。最为一个电子商务的站点，他包含的数据的关系比较简单，逻辑也非常清晰，这种情况下如果我们再对book, shopcart, order等等做对象建模，用纯OO的思路去做这样的一个网站，似乎有点为了体现“技术先进性”，而Dataset的出现在效率上提高了很多，整个网站的代码虽然含有一定demo的意义（N-tier的架构演示），但是在数据处理和操作上确实非常清晰明朗，代码的效率也比较高。
Typed Dataset的不足
这方面纯粹是我自己的一些体会，就上面也说到的，由Vs.net生成的代码非常臃肿，虽然这并不影响它的使用，但是毕竟如果需要对这个强类型的Dataset做些自定义的描述以及扩展，就不是非常方便。而如果你要自己手工写的话，那似乎又有背于它的提高开发效率的原意。其实除了用Vs.net的IDE生成，还可以通过Dataset的WriteXmlSchema方法和DOTNET SDK提供的xml工具协作创建强类型Dataset，但是毕竟还是有点麻烦。
总结
以上是我的一些个人理解，由于已经许久没有用到Dataset，虽然以前有过一些这方面的研究尝试，但是难免表达的不够全面，或是有些认识上的错误，还请多多指教。
先申明，本文只代表本人愚见，如有不同看法，请直接反驳。
什么是Typed Dataset
这个问题不知道有没有必要提，其实早先我对Typed Dataset的认识也是比较模棱两可的，用我的话讲就是“用实践来说话”。一般意义上讲，VS.Net提供了创建Typed Dataset的方法，虽然生成的代码很庞大，但是却很够用，而且估计很多人谈的Typed DataSet也就是指这个。
看过Duwamish7源码的人应该都知道，它的DAL里的实体就是以Dataset的形式呈现的，我早先还自以为是的给它冠以“强类型”Dataset的称谓，但是，严格意义上讲这种Dataset不能称为Typed Dataset。
用Truly的话来解释什么是Typed Dataset：
强类型DataSet是从DataSet继承的定制对象，它可以通过其显露的属性（properties）来对封装数据进行强类型的访问。
强类型DataSet避免了字段的晚绑定。强类型DataSet提供了强类型的访问器，因为避免了到一个集合中查找列名或表名，访问时更快。
除了能够提高运行时的性能，强类型DataSet还提供了类型检查，并且在设计时可以通过自定义字段名对字段智能感知。
强类型DataSet避免了字段的晚绑定。强类型DataSet提供了强类型的访问器，因为避免了到一个集合中查找列名或表名，访问时更快。
除了能够提高运行时的性能，强类型DataSet还提供了类型检查，并且在设计时可以通过自定义字段名对字段智能感知。
我的理解，Typed Dataset应该是
1. 继承于DataSet类的一个类；2. 提供对其所存储数据的架构的基本属性的直接访问；3. 本身应该包含次级容器的对象定义以及直接访问支持（即DataTable & DataRow）；4. 可以让开发人员更高效的编写数据访问的代码。个人认为，上面的最后一点是Typed Dataset的关键，虽然truly关注了它与普通dataset的性能差异，但是我还是觉得Typed Dataset很大程度上simplified the task of data navigation and operation。
Typed Dataset的应用
本来不想就这个东西的应用做讨论，因为说实话我觉得我还没有资格，我对Typed Dataset的应用还不多，一方面也是因为我觉得一个这样的类对我而言显得很臃肿，不说生成的代码，就它占用的内存就让我一定程度上只把他作为过度性的数据存储对象，更多时候我的实体对象类还是用自己写的小工具来生成。
但是就我的了解，M$推荐开发人员使用Dataset/Typed Dataset。确实，在大家都在大肆讨论ORM的时候，Dataset这个东西提供了一个简便的亦或是是轻量级（我个人这么认为）的O/R Mapping的机制，而强类型的Dataset更是更大限度的发挥了这方面的长处。
其实要说强类型的Dataset的应用，首先就先会想到普通的Dataset的一些应用，我见过一些朋友十分依赖Dataset，把它作为处理/存储数据的一个金钥匙，甚至毫无“保留”的作为保存状态的方式（存在Session中等等）。其实很大程度上变成了“滥用”。
Duwamish对Dataset的应用应该是做的很恰当的，虽然我说它的Dataset不算纯粹的Typed Dataset，但是，它的确具备了作为强类型的部分基本条件。最为一个电子商务的站点，他包含的数据的关系比较简单，逻辑也非常清晰，这种情况下如果我们再对book, shopcart, order等等做对象建模，用纯OO的思路去做这样的一个网站，似乎有点为了体现“技术先进性”，而Dataset的出现在效率上提高了很多，整个网站的代码虽然含有一定demo的意义（N-tier的架构演示），但是在数据处理和操作上确实非常清晰明朗，代码的效率也比较高。
Typed Dataset的不足
这方面纯粹是我自己的一些体会，就上面也说到的，由Vs.net生成的代码非常臃肿，虽然这并不影响它的使用，但是毕竟如果需要对这个强类型的Dataset做些自定义的描述以及扩展，就不是非常方便。而如果你要自己手工写的话，那似乎又有背于它的提高开发效率的原意。其实除了用Vs.net的IDE生成，还可以通过Dataset的WriteXmlSchema方法和DOTNET SDK提供的xml工具协作创建强类型Dataset，但是毕竟还是有点麻烦。
总结
以上是我的一些个人理解，由于已经许久没有用到Dataset，虽然以前有过一些这方面的研究尝试，但是难免表达的不够全面，或是有些认识上的错误，还请多多指教。
