从数据访问的角度认识一下duwamish
为了更灵活的数据访问，duwamish把中间业务层分成了businessfacade和businessroles两部分，关于这个的介绍大家可以看这个 -- 点击进入 --
先说一句很傻的话，facade层内部并不是自动处理什么请求该转rules，什么请求该转dataaccess，而是都设定好了，并且仅有很少的数据操作要经过rules（是很傻吧，不过当时我第一次看完这文章，还没有看duwamish的时候，我就这么想过，汗……）
还有就是，详细的数据流程msdn上都有，并且重要的部分还配有图片。
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用，具体到数据访问的过程，就是表示层的所有对数据访问的要求都传达给facade层，然后facade层内部进行处理，或者直接使用dataccess返回数据，或者把请求处理后交给rules，然后rules再把请求进行处理，最后调用dataaccess返回数据。
duwamish是一个简化的模型，主要是分成帐户、产品、定单的相关操作。
businessfacade的构成：customsystem、ordersystem、productsystem
businessrules的构成：custom、order
facade所做的事情包括所有这三个方面的相关活动，其中有一些仅仅是起到一个包装类的作用，既得到请求后立刻调用dataaccess的相关方法，但更多的是先对请求进行分析处理，然后再调用dataaccess的相关方法。
rules层只进行帐户（帐户的生成和修改）和定单（定单的生成和展示）的相关操作，因为这两部分相对来说比较复杂，要注意的是其接受的请求都是经过facade进行完处理的。
当facade和rules结合进行和数据库交互的活动的时候，facade的作用就是提前处理数据，而不管数据是否合法，rules得到的数据总是可以直接拿来用的，它只需要检查数据的合法性，保证数据有必要交给数据库。而如果facade得到的是完整的不需处理的数据，那它就变成了rules的一个包装类，facade会直接调用rules的相关方法。 看下面的例子。
帐户的生成：
1.facade层的CustomerSystem从web层的AccountModule处获得数据，将其中的明文密码进行加密，然后将数据组合成一个CustomerData，最后把数据传给rules层。
2.rules层的Customer需要对得到的CustomerData进行数据的验证和错误检查，还要判断该CustomerData的email是否已经存在，如果一切顺利，就将该CustomerData传给dataaccess进行最后的处理，否则就拒绝进行进一步操作，并返回错误。
3.dataaccess需要做的，只是将数据插入数据库，这个等会再说。
另外，当不必与数据库交互的时候，rules会提供一些工具方法给facade使用，rules进行业务规则的计算，而facade则负责对外的工作。比如下面的这个流程。
定单的展示：
1.web层的cart需要对定单进行处理，把原始数据传给facade层的OrderSystem。
2.OrderSystem调用rules层的Order的相关辅助方法进行tax和shipping charges的计算
3.OrderSystem把处理完的定单返回给cart。
上面说了facade和rules的配合，接下来看daraaccess的活动。
pethsop和duwamish代表了使用adp.net的两种方法，petshop使用的是datareader，而duwamish使用dataset，对于复杂操作，还是用datasert顺手，不是吗？
duwamish例对dataset的使用有点恐怖，它不是直接拿dataset来用，而是构造了一个类似于强类型dataset的类，这样做的好处估计是增加模型的易用性？其实这个dataset里都有放一个空表，依类型不同而不同，其实就是把数据库中相应表的结构复制了一下。当使用的时候可以直接拿来用，而无须用dataadapter的填充获得架构信息。从使用的角度看，这和petshop的model实体模型差不多。但是这样子显示比简单的实体类好用的多，因为是datatable，所以可以借助其丰富的功能实现数据查找替换等操作，而无须再像pstshop一样借助arraylist来完成某些操作。而duwamish的购物车更是直接使用了这个dataset模型，这样当然没有问题。
因为使用了dataset做为数据实体（？），所以数据操作就简单到使用dataadapter进行update或fill，而不用在额外的时候诸如daab等helper类辅助数据操作。dataadapter需要的各种command都是具体指定的，而不是由commandbuilder生成，这样即提高了性能，也可以直接进行update而不用先select（因为commandbuilder生成command的时候需要数据库架购信息，而这些信息必须要通过selectcommand的操作结果来提供）
接下来是command的生成，duwamish里没有通用的command生成方法，都是一个萝卜一个坑的方式生成各种需要的command，一般就是准备参数集合，设定CommandType和CommandText。
duwamish使用sp，有一些复杂的逻辑操作都由sp完成了，另外事务也是在sp中完成的。
在实际进行的时候，dataadapter都要先做好表映射，这样才能顺利的update。
先到这里了，今天简单的分析了一下duwamish的数据访问，都是我自己的想法，大家如果有别的想法可以一起讨论啊：）