前言：
上一篇文章讲述了一些实现DAL的理论，本篇主要是DAL实现的的初步的尝试。
本篇的主要议题如下：
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。
因为不同的表产生不同的数据实体，但是Richard还想使得AddSingleDataEntity这个方法可以接受任何的数据实体，所以此时很有必要对数据实体进行抽象。所以Richard想到了定义一个接口：IDataEntity,打算让所有通过ORM生成的数据实体都继承这个接口。而且Richard还想到：
1. 如果BLL直接引用DAL使用的，那么IDataEntity可能会在BLL中出现的。
2. 如果BLL通过repository去DAL中获取数据，那么到时候BLL可能都不会直接引用DAL，但是BLL最终还是得使用数据做事情，所以IDataEntity还是会在BLL中出现，所以，IDataEntity接口最好定义在一个公共的地方。
Richard决定新建一个Common的类库，加入IDataEntity接口的定义，现在这个接口里面什么都没有，只是一个标记而已，表明继承这个接口的类就是数据实体类。
AddSingleDataEntity(IDataEntity dataEntity);
还有一点就是尽量的使用类型安全的方法，于是Richard把方法改成了范型方法：
AddSingleDataEntity<T>(T dataEntity) where T:IDataEntity,class,new();
至于T 的那些约束：T:IDataEntity,class,new()，是考虑到了Linq和EF中对数据实体的一些要求。
