本篇的主要议题如下：
1.设计DAL的基本操作
2.对基本的操作的进一步的思考
3.查询对象的一些思考
1.设计DAL的基本操作
Richard认为：在设计一个架构或者Framework的时候，有几点很重要：
a.总体把握的能力。
b.抽象的能力。
c.分析的能力
首先，从总体上来看，Richard认为DAL中最基本，而且最容易想到的方法就是CRUD(Create, Read, Update, Delete)四个操作。
于是Richard在草纸写出了基本操作的名称：
AddSingleDataEntity;
AddDataEntityList;
UpdateSingleDataEntity;
UpdateDataEntityList;
DeleteSingleDataEntity;
DeleteDataEntityList;
GetSingleDataEntiry;
GetDataEntityList;
上面列出的方法名字很长，其实Richard在思考这些方法的名称的时候也参考了.NET设计规范中的一些建议：方法名称要具有“自解释性”，因为架构的设计最后还是给开发人员用的，所以方法的定义要一眼就看出它是干什么的，而且规范的命名也可以大大的减少维护的成本。(可能这些名字的命名有点对规范的 “生搬硬套”，但是之后会慢慢的重构的)
从总体出发，已经定义出了基本的操作，那么现在就开始一步步的分析，如何实现这些方法。
Richard开始思考第一个方法的实现，其实Richard心里也清楚：其实到底哪个方法作为第一个来考虑也许很重要，但是在一切都不清楚之前起码要拿一个来入手，而且随着思考的深入，很多的问题都会慢慢的浮现，到时候一切就会明晰起来。
对于AddSingleDataEntity这个方法，首先就要考虑这个方法到底要把什么添加到数据库中，也就是说要考虑这个方法的参数，而且这个参数要足够的“兼容”，因为之前Richard就是想设计出一个“以不变应万变”的DAL。在考虑这个参数问题之前，首先Richard很清楚：在.NET数据访问技术中，Linq，Entity Framework等ORM技术已经广泛的应用，所以在设计DAL的时候要充分的考虑到现有的一些技术(尽量避免重新造轮子)。
而且在数据是如何被存入到数据库中的以及数据是如何从数据库中取出的，这个工作是完全可以交给这些ORM的，最后的结果就是：在DAL中只是操作这些 ORM的那些映射实体。基于这个想法， Richard就确定了：AddSingleDataEntity参数是一个数据实体。(本系列文章约定：数据实体，即DataEntity，就是ORM 对一个数据库表进行映射后产生的实体和数据库中的表一一对应，如在数据库中有一张Employee表，Linq to Sql将会把它映射成为Employee的一个类，这个类就称为数据实体)。因为这些方法最终是操作数据实体的，所以包含这些方法的接口名字就定义为IDataContext。
