已经有两年多没有做过这种后台的增删改查的工作了,最近突然接到这种性质的工作,觉的如果还是和以前一样做的话,是不是有点太泛味了,之前的一年多本人学习了设计模式,对面向对象的理解比以前有所增加。理解当然的想起代码重构。
增删改查，从字面上来讲，无非就是四个操作，如果我们非要定义一个名称的话，我是这样定义的，ADD,Delete，Update，GetList，也就是说无论是针对哪张表的维护无外乎这四个操作，唯一的不同就是每个表在维护时对于实体的操作不同，我们一般都会把数据库的表映射到相应的实体类中，这点我们大可利用vs 2005就有的泛型来解决。下面我介绍下我的实现方式：
第一：项目结构介绍。这是不能少的。
1：MyChinaBusiness.IInterface，这个层用来放些接口或者是抽象类。
2：MyChinaBusiness.DAL，这个层是数据处理层。
3：MyChinaBusiness.BLL，这个层就是对应的业务逻辑层。
4：MyChinaBusiness.Web,这个自然是表示层了。
5：MyChinaBusiness.Model,这个层用来存放所有的实体对象。
第二：在IInterface层中创建一个抽象类DataOpration.cs，这个类是一个泛型类。作用就是对所有的后台增删改查操作进行约束。两个抽象方法Add,Update都非常好理解，至于下面的getList这里为什么定义了一个虚方法呢？那是因为我对取数据以前封装了一个比较通用的方法，所以这里想直接拿来复用，但这个方法会调用数据处理层的方法，如果直接把方法体拿过来会存在循环依赖的问题，所以这个方法只是简单返回一个空记录集，实际调用时，会在具体的业务逻辑类中重写它。
public abstract class DataOpration
它包含了我们常的三个方法，代码如下：
///
/// 添加数据
///
///
///
public abstract int Add(T t);
///
/// 修改数据
///
///
///
public abstract int Update(T t);
///
/// 读取记录集
///
///
///
///
///
///
///
///
///
///
public virtual DataTable getList(int iRowCount, int iPageNumber, string procName, string sCondition, string strsCompositor, out int pageCount, out int recordCount, out int iNextPageNumber)
{
pageCount = 0;
recordCount = 0;
iNextPageNumber = 0;
return new DataTable();
}
第三：下面是一个具体数据处理类：它实现了泛型抽象类,目的是为了进行方法签名的约束,其中的内容就是些常规的数据操作。注意这个类中并没有重写getList方法，原因上面已经分析过。
public class DAL_Regulations : DataOpration
{
#region 成员方法
///
/// 增加一条数据
///
public override int Add(Regulations model)
{
int rowsAffected;
SqlParameter[] parameters = {
new SqlParameter("@ID", SqlDbType.Int,4),
new SqlParameter("@Title", SqlDbType.NVarChar,200),
parameters[0].Direction = ParameterDirection.Output;
parameters[1].Value = model.Title;
parameters[5].Value = model.PostDate;
SqlHelper.ExecuteNonQuery(DAL_Comm.sConn, CommandType.StoredProcedure, "usp_Regulations_ADD", parameters);
return (int)parameters[0].Value;
}
///
/// 更新一条数据
///
public override int Update(Regulations model)
{
int rowsAffected;
SqlParameter[] parameters = {
new SqlParameter("@ID", SqlDbType.Int,4),
return SqlHelper.ExecuteNonQuery(DAL_Comm.sConn, CommandType.StoredProcedure, "usp_Regulations_Update", parameters);
}
#endregion 成员方法
}
第四：下面是对应的业务逻辑处理类：它同样需要实现泛型抽象类，下面重写的getList就是上面说的为什么抽象类中存在一个虚方法的问题，在业务逻辑层中调用数据处理类就解决了循环依赖的问题，同时为数据的提取方式留下了扩展的空间，虽然方法的参数固定，但实现的过程是可以重写的。
public class BLL_Regulations : DataOpration
{
private readonly DAL_Regulations dal=new DAL_Regulations();
#region 成员方法
///
/// 增加一条数据
///
public override int Add(Regulations model)
{
return dal.Add(model);
}
///
/// 更新一条数据
///
public override int Update(Regulations model)
{
return dal.Update(model);
}
///
/// 读取数据记录
/// add by minjiang 09-3-25
///
///
///
///
///
///
///
///
///
///
public override DataTable getList(int iRowCount, int iPageNumber, string procName, string sCondition, string strsCompositor, out int pageCount, out int recordCount, out int iNextPageNumber)
{
return DAL_Comm.getAll_Information(iRowCount, iPageNumber, procName, sCondition, strsCompositor, out pageCount, out recordCount, out iNextPageNumber);
}
#endregion 成员方法
}
第五：做了这么多，我们最后来看下表示层能得到什么好处。下面是表示层的部分代码：
首先：实例化一个具体的业务处理类给抽象类。
DataOpration _DataOpration = new BLL_Regulations();
然后：下面的操作就是调用抽象类的方法，Add,Update,getList。所有的增加,修改操作代码都一样，当然查询也是一样。
int i = _DataOpration.Add(model);
int j = _DataOpration.Update(model);
总结：做了这么多的封装，最后带来的好处就是：
1:代码结构较纯面向过程要清晰，因为所有的操作都体现在抽象类的定义中。
2:客户端代码进一步得到简化，无论是什么表的维护，对于增加，删除都是Add,Update,客户端不用关心方法名到底是什么。
3:这样做可以让一个后台维护工作由几个开发员分工合作，例如一个负责前台页面的处理，它最终调用抽象类的相关操作，但他并不关心如何实现，另一位开发人员只负责接收数据完成数据处理，这样在开发效率上会高很多，因为一个人负责一块的内容在熟练程序上会大大增加，理所当然的开发效率会提高。
本文作者:佚名 来源:http://www.cnblogs.com/ASPNET2008/archive/2009/03/
CIO之家 www.ciozj.com 微信公众号:imciow