在編寫數據庫操作方法時我們經常考慮方法內部處理的Connection, Transaction等,主要方便以後不同方法進行整合擴展。但很多時候寫數據庫操作方法都是封閉,在方法內部打開Connection或Transaction處理;這樣即滿足現有需求的需要,要省下了調用方法所帶來的麻煩事(因為在調用方法裡必須定義Connection等信息傳進去)。雖然這樣滿足了現有的需求,但面對以後在功能擴展需要整合幾個方法時問題就產生了,因為方法是封閉的當你需多個方法同時使用一個Connection或Transaction就必須修改原有方法;雖然可以對方法重載一個新版來適應新的需要,但是代碼的修改和重構也不是一件輕松的工作。
簡單地描述一下問題:
public void a()
{
........
}
public void b()
{
…….
}
以上兩個方法單獨使用並沒有什麼問題,因為它們都是獨立的。當出現下面情況又是如何呢?
Public void c()
{
a();
b();
….
}
在執行這個方法時有可能要保證a和b裡面的數據庫訪問必須使用同一個Connection,如果需要數據完全整性還要確保兩個方法的數據操作都必須使用同一個Transaction。由於剛開始編寫a和b方法沒有考慮這些情況,這個時候我們能做的只有把a和b方法進行重構來滿足原有和現在的需要。
如果我們不修改a和b就能滿足c的需要那是件多麼好的事情,這樣開發人員就有更多的時間去處理業務相關的麻煩事情。有時想一下dotNET提供一個DataContext(數據庫操作上下文對象)該多好啊,在編寫數據庫操作代碼時不用關心使用什麼的Connection和Transaction;通過當前的DataContext來確定。雖然自己有這樣的想法去實現,不過dotNET能提供是件最好不過的事情。
Public void c()
{
using(DataContext context = new DataContext())
{
a();
b();
….
}
}
Public void D()
{
using(DataContext context = new DataContext())
{
c();
….
}
}
補充一下:
其實在我的想法中DataContext不一定要顯式創建,可以通過配置的方式在中程序設置一個默認的DataContext。以下代碼的功能沒有完全實現。
Table orders = new Table("Orders");
Table orderdetails = new Table("[Order Details]");
orderdetails.Delete(OrderDetails._OrderID == 10500);
orders.Delete(Orders._OrderID == 10500);
即使不用顯式創建DataContext 上面代碼也可以運行。為了保證數據完整性可以這樣做:
using(TransactionContext tran = new TransactionContext())
{
Table orders = new Table("Orders");
Table orderdetails = new Table("[Order Details]");
orderdetails.Delete(OrderDetails._OrderID == 10500);
orders.Delete(Orders._OrderID == 10500);
tran.Commit();
}
在寫代碼的過程就可以把這些東西拋開,需要時候定義相應的DataContext就可以了。
如果需要高度透明性,只有一個DataContext是遠遠不夠的,必須提供相應數據操作的封裝。