对增删改查用面向对象进行包装

      已经有两年多没有做过这种后台的增删改查的工作了,最近突然接到这种性质的工作,觉的如果还是和以前一样做的话,是不是有点太泛味了,之前的一年多本人学习了设计模式,对面向对象的理解比以前有所增加。理解当然的想起代码重构。

      增删改查，从字面上来讲，无非就是四个操作，如果我们非要定义一个名称的话，我是这样定义的，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:这样做可以让一个后台维护工作由几个开发员分工合作，例如一个负责前台页面的处理，它最终调用抽象类的相关操作，但他并不关心如何实现，另一位开发人员只负责接收数据完成数据处理，这样在开发效率上会高很多，因为一个人负责一块的内容在熟练程序上会大大增加，理所当然的开发效率会提高。

转载于:https://www.cnblogs.com/ASPNET2008/archive/2009/03/26/1422040.html