前言：本篇之所以稱為草稿設計，是因為設計的都是在紙上完成的。反映了一個思考的過程。
本篇的議題如下：
1.第一個數據層草圖的提出
2.對數據訪問層的思考
3.第二個數據層草圖的提出
1.數據層草圖的提出
Richard開始著手設計，一開始他沒有就立刻在自己的計算機開始敲代碼。而且采用筆＋紙開始構思。
因為他認為：寫程序不是什麼時候都得上機，腦子裡面想什麼的才是最重要的，往往很多時候，在設計程序時，首先在頭腦中就已經把整個功能已經實現了，甚至代碼的詳細編寫都已經在頭腦中走了一遍，並且在頭腦中”運行，調試”了。
開始設計了，因為這次Richard想要提出一個比較好的架構，一個比較強大的企業級的架構，所以參看成功的一些案例是很有必要，Richard也就想到了微軟best practice的那些推薦的架構組織方式和建議（大家對best practice不熟悉也要緊，不會影響閱讀）。
之後，Richard的第一個草圖就出來了：
一個架構組織方式的提出，不是隨隨便便就提出的，新的架構的設計和提出首先必須要明白你要解決哪些問題，而且也不要”過度設計”。(這個過程很難，很多時候需要權衡，所以作為架構的設計者，權衡的思想很重要：在時間，資源，資金等都要考慮)。可能在起初會參看一些別的設計架構，甚至是模仿它們，但是隨著思考的深入，那些表象的東西就會逐漸的被拋除。
同時也開始設計的時候，沒有說一定要立刻就要設計出一個很強大的東西出來，對架構設計的能力也是在慢慢的演化和思考過程中提升的。
2.對數據訪問層的思考
在解釋為什麼架構要像上面那副圖進行設計之前，我們首先來討論一些之前項目問題：
對於數據訪問層(DAL)的問題：
1.DAL很依賴Linq生成的實體。可以說在之前的項目中，在數據訪問層能夠使用的技術就已經”釘死”在了Linq上。這裡不是說Linq不好，而且強調在DAL的訪問技術的選擇的余地已經沒有了，不靈活。
a)在架構的設計過程中，就需要考慮到以後技術的轉變和更換，可能在項目A中采用Linq to sql，但是在項目B中就采用Entity Framework。因為我們的目的就是要開發一個比較靈活的通用架構，能夠支持不同就數據訪問技術。可能以後的項目都只是用一種訪問技術，但是最為架構的設計者，特別是希望從架構最後能夠演化到Framework, 那就要為更換技術預留接口。
2.在DAL中沒有很多的異常處理等底層機制。
a)在項目設計的過程中，有些底層的機制是幾乎每一個邏輯都要用到的：異常處理，日志跟蹤，緩存機制，事務機制，安全驗證機制。當時在之前的DAL中是沒有的。可能現在你認為有些機制不是需要的，或者不明白為什麼需要。
因為一個強大的軟件，不能隨隨便便就因為某些異常或者錯誤就崩潰了，也不可能就是一大堆代碼的堆砌。上面所提到的有些機制：如異常，日志，它們的價值很多時候在軟件維護的時候體驗出來。根據日志記錄，可以查處軟件哪裡出了問題，如是數據庫斷了，還是哪個操作流程導致了問題。 而有些機制是在運行時體現價值，如緩存，驗證，事務。
但是在使用這些底層機制的時候也要權衡，綜合的考慮，如緩存機制，就得明白那些數據要緩存，緩存在哪裡，緩存數據時候要加密，緩存多長時間，如何刷新過期了的數據。等等，很多東西要考慮。
3.數據來源僅僅只是考慮了數據庫。其實這個問題不是之前的項目的一個問題，但是這裡有必要提出。
a)一般在我們開發項目的時候，數據的來源很多時候都是數據庫，我們直接操作數據庫就行了，但是還得考慮一個問題：如果我們的項目沒有自己的數據庫，我們的數據來源是來自其他的公司或者服務接口，怎麼辦？作為架構的設計者，是需要考慮這些的。
可能在項目敲定那天就已經清楚是自己設計數據庫還是從其他地方獲取數據。但是一個通用的一個架構的就要能夠為其他的數據源預留接口。
這裡，可能就有了一點”過度設計”的味道了，起初在項目A中所使用的架構沒有考慮其他數據源的問題，但是如果在項目B中出現了，怎麼辦？那麼架構就要演化，改進來適應這種情況。
之前也提過，沒有必要一上來就設計強大的就架構，而是在項目中改進，演化。開始時候沒有考慮到，以後慢慢的加嘛。(比較的糾結)。
上面只是緊緊的從數據層DAL的角度進行了思考，DAL最終還是為業務層BLL提供數據的，所以就考慮DAL以何種方式來被BLL調用，鑒於之前的一些考慮，可以得出一點：不讓BLL直到DAL的實現細節，所以接口似乎是個不錯的解決辦法，Provider的模式也似乎可以排上用場。
於是,Richard就決定在DAL和BLL之前加上接口層來解耦。
3.第二個數據層草圖的提出
這個圖和之前的第一個圖基本上是一樣的，只是做了一修改，而且加上了之前談論中涉及的一些問題。
因為隨著思考的深入，逐漸的發覺：數據源的來源可以很多—數據庫，普通文本，XML等等。不同的數據源提供不同的Provider，其實從其他的服務接口獲取數據也是一種來源，上面的圖之所以單獨的把Service Agent分出，主要是因為比較特殊。
而且圖中的那些基本功能：Log, Exception等，是到處都用到的。
此時Richard也在頭腦中閃現了一些要處理的，可以出現的異常：
1.Data Source is not exits:數據源不存在，因為這個問題很常見，比如在項目運行過程中，數據庫斷了，或者遠程的服務無法訪問，等等基本都屬於這個問題的。所以這個異常肯定是要處理的。
2.Time out:超時。這個異常很常見，獲取的數據過大，或者遠程數據源連接超時，等，都可以引發一些問題。
3.如果數據源是其他服務接口提供數據，那麼在數據獲取時，可能要轉換數據格式，如果格式出錯，。或者發送的數據不符合一些規則，這個異常一定要處理，因為這些數據可能涉及到安全的問題了：是數據真的不正確，還是被篡改了。
程序就必須對這些異常進行處理：是把原生的異常拋出，然後有業務層決定如果處理；還是決定把異常包裝稱為另外的一個異常，再拋出；還是最後干脆再DAL就執行自己處理，然後給業務層一個友好的提示，等等。如果數據源是遠程的服務，那麼如果服務斷了，在異常過程中，采用什麼樣的策略：簡單的處理，如拋出異常，記錄日志，還是做一些恢復性的操作，如嘗試重新連接，等。
之前第一張圖中，在DAL上定義一個接口，用來接耦，但是在第二張圖有做了一些修改－－把DAL做為服務提供出去。之所以做了這個修改，因為在開始思考的時候，只是認為底層設計的DAL只是給BLL使用。可以發覺到一點：在DAL中，數據可以從遠程的服務中獲取，那麼可能我們這裡的DAL也可以作為服務給其他的人設計的DAL使用，也就是說，我們的這裡的DAL成了遠程服務的數據源。所以做了上面的修改。但是這個思考到還會改進，因為這裡面問題(讀者朋友可以先自己思考是什麼問題)。
今天就寫到這裡了，謝謝各位！
下篇講述---.NET 分布式架構開發實戰之三 數據訪問深入一點的思考
出處：http://www.cnblogs.com/yanyangtian
