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

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


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

posted on 2009-03-26 11:14  min.jiang  阅读(9509)  评论(42编辑  收藏  举报