前言：

　　本篇之所以稱為草稿設(shè)計，是因為設(shè)計的都是在紙上完成的。反映了一個思考的過程。

　　本篇的議題如下：

　　1） 第一個數(shù)據(jù)層草圖的提出

　　2） 對數(shù)據(jù)訪問層的思考

　　3） 第二個數(shù)據(jù)層草圖的提出

　　1.數(shù)據(jù)層草圖的提出

　　Richard開始著手設(shè)計，一開始他沒有就立刻在自己的計算機開始敲代碼。而且采用筆＋紙開始構(gòu)思。

　　因為他認(rèn)為：寫程序不是什么時候都得上機，腦子里面想什么的才是最重要的，往往很多時候，在設(shè)計程序時，首先在頭腦中就已經(jīng)把整個功能已經(jīng)實現(xiàn)了，甚至代碼的詳細編寫都已經(jīng)在頭腦中走了一遍，并且在頭腦中運行，調(diào)試了。

　　開始設(shè)計了，因為這次Richard想要提出一個比較好的架構(gòu)，一個比較強大的企業(yè)級的架構(gòu)，所以參看成功的一些案例是很有必要，Richard也想到了微軟best practice的那些推薦的架構(gòu)組織方式和建議（大家對best practice不熟悉也要緊，不會影響閱讀）。

　　之后，Richard的第一個草圖就出來了：

　　一個架構(gòu)組織方式的提出，不是隨隨便便就提出的，新的架構(gòu)的設(shè)計和提出首先必須要明白你要解決哪些問題，而且也不要過度設(shè)計。（這個過程很難，很多時候需要權(quán)衡，所以作為架構(gòu)的設(shè)計者，權(quán)衡的思想很重要：在時間，資源，資金等都要考慮）。可能在起初會參看一些別的設(shè)計架構(gòu)，甚至是模仿它們，但是隨著思考的深入，那些表象的東西就會逐漸的被拋除。

　　同時也開始設(shè)計的時候，沒有說一定要立刻就要設(shè)計出一個很強大的東西出來，對架構(gòu)設(shè)計的能力也是在慢慢的演化和思考過程中提升的。

　　2. 對數(shù)據(jù)訪問層的思考

　　在解釋為什么架構(gòu)要像上面那副圖進行設(shè)計之前，我們首先來討論一些之前項目問題：

　　對于數(shù)據(jù)訪問層（DAL）的問題：

　　1. DAL很依賴Linq生成的實體。可以說在之前的項目中，在數(shù)據(jù)訪問層能夠使用的技術(shù)就已經(jīng)釘死在了Linq上。這里不是說Linq不好，而且強調(diào)在DAL的訪問技術(shù)的選擇的余地已經(jīng)沒有了，不靈活。

　　a） 在架構(gòu)的設(shè)計過程中，就需要考慮到以后技術(shù)的轉(zhuǎn)變和更換，可能在項目A中采用Linq to sql，但是在項目B中就采用Entity Framework。因為我們的目的就是要開發(fā)一個比較靈活的通用架構(gòu)，能夠支持不同就數(shù)據(jù)訪問技術(shù)。可能以后的項目都只是用一種訪問技術(shù)，但是最為架構(gòu)的設(shè)計者，特別是希望從架構(gòu)最后能夠演化到Framework， 那就要為更換技術(shù)預(yù)留接口。

　　2. 在DAL中沒有很多的異常處理等底層機制。

　　a） 在項目設(shè)計的過程中，有些底層的機制是幾乎每一個邏輯都要用到的：異常處理，日志跟蹤，緩存機制，事務(wù)機制，安全驗證機制。當(dāng)時在之前的DAL中是沒有的。可能現(xiàn)在你認(rèn)為有些機制不是需要的，或者不明白為什么需要。

　　因為一個強大的軟件，不能隨隨便便就因為某些異常或者錯誤就崩潰了，也不可能就是一大堆代碼的堆砌。上面所提到的有些機制：如異常，日志，它們的價值很多時候在軟件維護的時候體驗出來。根據(jù)日志記錄，可以查處軟件哪里出了問題，如是數(shù)據(jù)庫斷了，還是哪個操作流程導(dǎo)致了問題。 而有些機制是在運行時體現(xiàn)價值，如緩存，驗證，事務(wù)。

　　但是在使用這些底層機制的時候也要權(quán)衡，綜合的考慮，如緩存機制，就得明白那些數(shù)據(jù)要緩存，緩存在哪里，緩存數(shù)據(jù)時候要加密，緩存多長時間，如何刷新過期了的數(shù)據(jù)。等等，很多東西要考慮。

　　3. 數(shù)據(jù)來源僅僅只是考慮了數(shù)據(jù)庫。其實這個問題不是之前的項目的一個問題，但是這里有必要提出。

　　a） 一般在我們開發(fā)項目的時候，數(shù)據(jù)的來源很多時候都是數(shù)據(jù)庫，我們直接操作數(shù)據(jù)庫就行了，但是還得考慮一個問題：如果我們的項目沒有自己的數(shù)據(jù)庫，我們的數(shù)據(jù)來源是來自其他的公司或者服務(wù)接口，怎么辦？作為架構(gòu)的設(shè)計者，是需要考慮這些的。NET 分布式架構(gòu)開發(fā)實戰(zhàn)之二 草稿設(shè)計

　　可能在項目敲定那天就已經(jīng)清楚是自己設(shè)計數(shù)據(jù)庫還是從其他地方獲取數(shù)據(jù)。但是一個通用的一個架構(gòu)的就要能夠為其他的數(shù)據(jù)源預(yù)留接口。

　　這里，可能就有了一點過度設(shè)計的味道了，起初在項目A中所使用的架構(gòu)沒有考慮其他數(shù)據(jù)源的問題，但是如果在項目B中出現(xiàn)了，怎么辦？那么架構(gòu)就要演化，改進來適應(yīng)這種情況。

　　之前也提過，沒有必要一上來就設(shè)計強大的就架構(gòu)，而是在項目中改進，演化。開始時候沒有考慮到，以后慢慢的加嘛。（比較的糾結(jié)）。

　　上面只是緊緊的從數(shù)據(jù)層DAL的角度進行了思考，DAL最終還是為業(yè)務(wù)層BLL提供數(shù)據(jù)的，所以就考慮DAL以何種方式來被BLL調(diào)用，鑒于之前的一些考慮，可以得出一點：不讓BLL直到DAL的實現(xiàn)細節(jié)，所以接口似乎是個不錯的解決辦法，Provider的模式也似乎可以排上用場。

　　于是，Richard就決定在DAL和BLL之前加上接口層來解耦。

　　3. 第二個數(shù)據(jù)層草圖的提出

　　這個圖和之前的第一個圖基本上是一樣的，只是做了一修改，而且加上了之前談?wù)撝猩婕暗囊恍﹩栴}。

　　因為隨著思考的深入，逐漸的發(fā)覺：數(shù)據(jù)源的來源可以很多—數(shù)據(jù)庫，普通文本，XML等等。不同的數(shù)據(jù)源提供不同的Provider，其實從其他的服務(wù)接口獲取數(shù)據(jù)也是一種來源，上面的圖之所以單獨的把Service Agent分出，主要是因為比較特殊。

　　而且圖中的那些基本功能：Log， Exception等，是到處都用到的。

　　此時Richard也在頭腦中閃現(xiàn)了一些要處理的，可以出現(xiàn)的異常：

　　1.Data Source is not exits：數(shù)據(jù)源不存在，因為這個問題很常見，比如在項目運行過程中，數(shù)據(jù)庫斷了，或者遠程的服務(wù)無法訪問，等等基本都屬于這個問題的。所以這個異常肯定是要處理的。

　　2. Time out：超時。這個異常很常見，獲取的數(shù)據(jù)過大，或者遠程數(shù)據(jù)源連接超時，等，都可以引發(fā)一些問題。

　　3. 如果數(shù)據(jù)源是其他服務(wù)接口提供數(shù)據(jù)，那么在數(shù)據(jù)獲取時，可能要轉(zhuǎn)換數(shù)據(jù)格式，如果格式出錯，。或者發(fā)送的數(shù)據(jù)不符合一些規(guī)則，這個異常一定要處理，因為這些數(shù)據(jù)可能涉及到安全的問題了：是數(shù)據(jù)真的不正確，還是被篡改了。

　　程序就必須對這些異常進行處理：是把原生的異常拋出，然后有業(yè)務(wù)層決定如果處理；還是決定把異常包裝稱為另外的一個異常，再拋出；還是最后干脆再DAL就執(zhí)行自己處理，然后給業(yè)務(wù)層一個友好的提示，等等。如果數(shù)據(jù)源是遠程的服務(wù)，那么如果服務(wù)斷了，在異常過程中，采用什么樣的策略：簡單的處理，如拋出異常，記錄日志，還是做一些恢復(fù)性的操作，如嘗試重新連接，等。

　　之前第一張圖中，在DAL上定義一個接口，用來接耦，但是在第二張圖有做了一些修改－－把DAL做為服務(wù)提供出去。之所以做了這個修改，因為在開始思考的時候，只是認(rèn)為底層設(shè)計的DAL只是給BLL使用。可以發(fā)覺到一點：在DAL中，數(shù)據(jù)可以從遠程的服務(wù)中獲取，那么可能我們這里的DAL也可以作為服務(wù)給其他的人設(shè)計的DAL使用，也就是說，我們的這里的DAL成了遠程服務(wù)的數(shù)據(jù)源。所以做了上面的修改。但是這個思考到還會改進，因為這里面問題（讀者朋友可以先自己思考是什么問題）。

　　相關(guān)文章：.NET分布式架構(gòu)開發(fā)實戰(zhàn)之一 故事起源

                     .NET 分布式架構(gòu)開發(fā)實戰(zhàn)之三 數(shù)據(jù)訪問深入一點的思考

                     .NET 分布式架構(gòu)開發(fā)實戰(zhàn)之四 構(gòu)建從理想和實現(xiàn)之間的橋梁（前篇）

NET技術(shù)：.NET 分布式架構(gòu)開發(fā)實戰(zhàn)之二 草稿設(shè)計，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。