已經有兩年多沒有做過這種後台的增刪改查的工作了,最近突然接到這種性質 的工作,覺的如果還是和以前一樣做的話,是不是有點太泛味了,之前的一年多本人 學習了設計模式,對面向對象的理解比以前有所增加。理解當然的想起代碼重構。
增刪改查，從字面上來講，無非就是四個操作，如果我們非要定義一個名稱的 話，我是這樣定義的，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:這樣做可以讓一個後台維護工作由幾個開發員分工合作，例如一個負責前台 頁面的處理，它最終調用抽象類的相關操作，但他並不關心如何實現，另一位開 發人員只負責接收數據完成數據處理，這樣在開發效率上會高很多，因為一個人 負責一塊的內容在熟練程序上會大大增加，理所當然的開發效率會提高。
