已经有两年多没有做过这种后台的增删改查的工作了,最近突然接到这种性质的工作,觉的如果还是和以前一样做的话,是不是有点太泛味了,之前的一年多本人学习了设计模式,对面向对象的理解比以前有所增加。理解当然的想起代码重构。
增删改查，从字面上来讲，无非就是四个操作，如果我们非要定义一个名称的话，我是这样定义的，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<T>
         它包含了我们常的三个方法，代码如下：
         /**//// <summary>
       /// 添加数据
       /// </summary>
       /// <param name="t"></param>
       /// <returns></returns>
      public  abstract int Add(T t);
       /**//// <summary>
       /// 修改数据
       /// </summary>
       /// <param name="t"></param>
       /// <returns></returns>
      public  abstract int Update(T t);
       /**//// <summary>
       /// 读取记录集
       /// </summary>
       /// <param name="iRowCount"></param>
       /// <param name="iPageNumber"></param>
       /// <param name="procName"></param>
       /// <param name="sCondition"></param>
       /// <param name="strsCompositor"></param>
       /// <param name="pageCount"></param>
       /// <param name="recordCount"></param>
       /// <param name="iNextPageNumber"></param>
       /// <returns></returns>
       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<Regulations>  
    ...{
        成员方法#region  成员方法
        /**//// <summary>
        ///  增加一条数据
        /// </summary>
        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;
        }

        /**//// <summary>
        ///  更新一条数据
        /// </summary>
        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<Regulations>  
    ...{
       private readonly DAL_Regulations dal=new DAL_Regulations();
  
  成员方法#region  成员方法
  /**//// <summary>
  /// 增加一条数据
  /// </summary>
  public override  int  Add(Regulations model)
  ...{
   return dal.Add(model);
  }

  /**//// <summary>
  /// 更新一条数据
  /// </summary>
  public override  int Update(Regulations model)
  ...{
   return  dal.Update(model);
  }
        /**//// <summary>
        /// 读取数据记录
        /// add by minjiang 09-3-25
        /// </summary>
        /// <param name="iRowCount"></param>
        /// <param name="iPageNumber"></param>
        /// <param name="procName"></param>
        /// <param name="sCondition"></param>
        /// <param name="strsCompositor"></param>
        /// <param name="pageCount"></param>
        /// <param name="recordCount"></param>
        /// <param name="iNextPageNumber"></param>
        /// <returns></returns>
        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<Regulations> _DataOpration = new BLL_Regulations();

然后：下面的操作就是调用抽象类的方法，Add,Update,getList。所有的增加,修改操作代码都一样，当然查询也是一样。

int i = _DataOpration.Add(model);
int j = _DataOpration.Update(model);

总结：做了这么多的封装，最后带来的好处就是：
1:代码结构较纯面向过程要清晰，因为所有的操作都体现在抽象类的定义中。
2:客户端代码进一步得到简化，无论是什么表的维护，对于增加，删除都是Add,Update,客户端不用关心方法名到底是什么。

3:这样做可以让一个后台维护工作由几个开发员分工合作，例如一个负责前台页面的处理，它最终调用抽象类的相关操作，但他并不关心如何实现，另一位开发人员只负责接收数据完成数据处理，这样在开发效率上会高很多，因为一个人负责一块的内容在熟练程序上会大大增加，理所当然的开发效率会提高。