在編寫數(shù)據(jù)庫操作方法時我們經(jīng)常考慮方法內(nèi)部處理的Connection, Transaction等，主要方便以后不同方法進(jìn)行整合擴(kuò)展。但很多時候?qū)憯?shù)據(jù)庫操作方法都是封閉，在方法內(nèi)部打開Connection或Transaction處理；這樣即滿足現(xiàn)有需求的需要，要省下了調(diào)用方法所帶來的麻煩事（因為在調(diào)用方法里必須定義Connection等信息傳進(jìn)去）。雖然這樣滿足了現(xiàn)有的需求，但面對以后在功能擴(kuò)展需要整合幾個方法時問題就產(chǎn)生了，因為方法是封閉的當(dāng)你需多個方法同時使用一個Connection或Transaction就必須修改原有方法；雖然可以對方法重載一個新版來適應(yīng)新的需要，但是代碼的修改和重構(gòu)也不是一件輕松的工作。

    簡單地描述一下問題：

    public void a()

    {

              ........

}

public void b()

{

       …….

}

以上兩個方法單獨使用并沒有什么問題，因為它們都是獨立的。當(dāng)出現(xiàn)下面情況又是如何呢？

Public void c()

{

a();

b();

….

}

在執(zhí)行這個方法時有可能要保證a和b里面的數(shù)據(jù)庫訪問必須使用同一個Connection，如果需要數(shù)據(jù)完全整性還要確保兩個方法的數(shù)據(jù)操作都必須使用同一個Transaction。由于剛開始編寫a和b方法沒有考慮這些情況，這個時候我們能做的只有把a和b方法進(jìn)行重構(gòu)來滿足原有和現(xiàn)在的需要。

如果我們不修改a和b就能滿足c的需要那是件多么好的事情，這樣開發(fā)人員就有更多的時間去處理業(yè)務(wù)相關(guān)的麻煩事情。有時想一下dotNET提供一個DataContext（數(shù)據(jù)庫操作上下文對象）該多好啊，在編寫數(shù)據(jù)庫操作代碼時不用關(guān)心使用什么的Connection和Transaction；通過當(dāng)前的DataContext來確定。雖然自己有這樣的想法去實現(xiàn)，不過dotNET能提供是件最好不過的事情。

Public void c()

{

    using(DataContext context = new DataContext())

{

a();

b();

….

}

}

Public void D()

{

using(DataContext context = new DataContext())

{

c();

….

}

     }

補充一下：
其實在我的想法中DataContext不一定要顯式創(chuàng)建，可以通過配置的方式在中程序設(shè)置一個默認(rèn)的DataContext。
以下代碼的功能沒有完全實現(xiàn)。
　　Table orders = new Table("Orders");
    Table orderdetails = new Table("[Order Details]");
    orderdetails.Delete(OrderDetails._OrderID == 10500);
    orders.Delete(Orders._OrderID == 10500);
即使不用顯式創(chuàng)建DataContext 上面代碼也可以運行。
為了保證數(shù)據(jù)完整性可以這樣做：
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();
｝
在寫代碼的過程就可以把這些東西拋開，需要時候定義相應(yīng)的DataContext就可以了。

如果需要高度透明性，只有一個DataContext是遠(yuǎn)遠(yuǎn)不夠的，必須提供相應(yīng)數(shù)據(jù)操作的封裝。