其它
结束ADONET剖析前不得不提提DataReader与DataSet间的兄弟之争
就作者所看过的资料几乎所有的都建议实际情况具体分析剩下很少很少的则全凭个人习惯决定
在学习ADONET时作者也是抱着这样的想法并反复牢记资料上总结的那些条款（就像当年学习GOF 条时那样几乎可以倒背如流了J）想到终有一日也可在ADONET下大展神威了
可惜现实不随人愿连续做了几个项目无论规模大小竟然全部采用了DataSet解决方案！
此时再回头看看学习ADONET时打开最为频繁的PetShop项目两相一比较这才看出些许端倪
简单的说PetShop采用了如下这种曲线救国的方式来实现数据交换
DataReader获取数据 => 创建数据实体类 => 根据字段类型填充数据实体类 => 将数据实体添加到列表类中（仅针对返回超过一条数据的场合）
（补充采用数据实体类或者集合类可以比较方便的实现Cache Manament而普通的DataReader由于其数据读取方式限制无法满足这种需求）
这个过程与DataAdapterFill() 所所产生的效果大同小异只不过
在Fill() 中DataAdpater自动创建DataReader去获取数据之后创建DataTable（相当于数据实体类）并根据字段类型填充DataTable当然如果可能返回多条记录DataTable完全可以处理就没必要去实现列表操作了
可能读者马上产生了疑问既然如此PetShop中为何还需要数据实体类呢？这其中还是有一些差别的
首先数据实体类是轻量级的structure一般仅包含数据字段没有
什么操作方法这比DataTable或者DataRow还是有一些性能上的优势（在数据量不大时可以忽略不计）另一方面数据实体类的操作相对简单不需要开发人员具备任何ADONET知识（其实就DataTable来说这也不算什么问题）点点属性就可以了
不过根据作者的实践来看这两方面似乎还不足以使人转而使用DataReader方案理由列举如下
（）对于数据量较大的场合可以采用分批读取的方式这有点类似DataGrid的数据分页效果
（）对于简单的数据实体类还能应付一旦涉及关联数据就只能另外撰写方法了而所有这些在DataSet中是非常容易处理的（对于企业级应用大部分情况都需要处理比较复杂的数据）
（）DataTable天生就支持数据集合操作这样的特性比集合+实体的混合模式（PetShop）更容易控制也更自然
（）实体类在声明时需要确定所有数据类型当进行数据填充时就需要DataReader再次关注实体所对应的数据类型不能有丝毫差错！在这方面DataTable就显得非常方便操作时只需要一次类型关注即可
（）DataSet解决方案可以非常方便的支持序列化操作（如RemotingWebServices）同时与XML的关系更是亲密无比这对于和其它系统的交互来说也是至关重要的
分析过一些技术和方案相信读者朋友已有一些体会值此收官之际如果非要在这里提供一个综上所述那作者的建议就非常明确在企业级应用开发中尽可能的采用DataSet（DataTable / DataView）+ Cache Management解决方案！
其它开发中只在如下种情况才考虑使用DataReader（就作者经验来说大部分使用DataReader都属第２种情况）
（）对资源要求比较苛刻的场合这里的资源主要指内存和数据库连接
（）希望在读取数据库返回结果集时作自定义处理例如在读取一条记录后立刻终止处理或者在读取时作计算操作
（提示这种情况类似于XML中的SAX（Simple API for XML）技术无需一次性读入所有XML数据即可进行操作相反的DOM（Document Object Model）则要求必须装载所有XML数据后才能开始操作（MSXML已开始允许只读取XML文档部分数据即可开始操作这是后话）!）
（） 只希望得到返回记录数或者返回记录的部分字段如
string GetNameByID(int nID) //根据员工ID返回员工姓名这里只需要
// 读取姓名字段
（提示这种情况一般可以通过执行特定的查询或存储过程直接解决）
（）出于某些方面的考虑（例如nTier系统中严格区分各Layer间的职责）无法（或者禁止）通过数据库本身进行查询过滤这时就只有使用DataReader在读取时进行过滤操作！
（提示虽然DataView也能达到这种目的但它的过滤前提是必须读取到所有返回数据所以性能上不如DataReader！）
