.NET 分布式架構開發實戰之二 草稿設計
前言：本篇之是以稱為草稿設計，是因為設計的都是在紙上完成的。反映了一個思考的過程。
本篇的議題如下：
1. 第一個資料層草圖的提出
2. 對資料通路層的思考
3. 第二個資料層草圖的提出
系列文章連結:
<a href="http://www.cnblogs.com/yanyangtian/archive/2010/05/24/1742432.html">[原創].NET 分布式架構開發實戰之二 草稿設計</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/05/26/1744064.html">[原創].NET 分布式架構開發實戰之三 資料通路深入一點的思考</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/05/28/1746334.html">[原創].NET 分布式架構開發實戰之四 建構從理想和實作之間的橋梁(前篇)</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/05/31/1747811.html">[原創].NET 分布式架構開發實戰五 Framework改進篇</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/06/03/1750444.html">[原創].NET 業務架構開發實戰之六 DAL的重構</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/06/07/1752921.html">[原創].NET 業務架構開發實戰之七 業務層初步構想</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/06/09/1754426.html">[原創].NET 業務架構開發實戰之八 業務層Mapping的選擇政策</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/06/17/1759327.html">[原創].NET 業務架構開發實戰之九 Mapping屬性原理和驗證規則的實作政策</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/06/28/1766442.html">[原創].NET 業務架構開發實戰之十 第一階段總結，深入淺出，水到渠成（前篇）</a> <a href="http://www.cnblogs.com/yanyangtian/archive/2010/06/28/1766460.html">[原創].NET 業務架構開發實戰之十 第一階段總結，深入淺出，水到渠成（後篇）</a>
1.資料層草圖的提出
Richard開始着手設計，一開始他沒有就立刻在自己的計算機開始敲代碼。而且采用筆＋紙開始構思。
因為他認為：寫程式不是什麼時候都得上機，腦子裡面想什麼的才是最重要的，往往很多時候，在設計程式時，首先在頭腦中就已經把整個功能已經實作了，甚至代碼的詳細編寫都已經在頭腦中走了一遍，并且在頭腦中”運作，調試”了。
開始設計了，因為這次Richard想要提出一個比較好的架構，一個比較強大的企業級的架構，是以參看成功的一些案例是很有必要，Richard也就想到了微軟best practice的那些推薦的架構組織方式和建議（大家對best practice不熟悉也要緊，不會影響閱讀）。
之後，Richard的第一個草圖就出來了：
一個架構組織方式的提出，不是随随便便就提出的，新的架構的設計和提出首先必須要明白你要解決哪些問題，而且也不要”過度設計”。(這個過程很難，很多時候需要權衡，是以作為架構的設計者，權衡的思想很重要：在時間，資源，資金等都要考慮)。可能在起初會參看一些别的設計架構，甚至是模仿它們，但是随着思考的深入，那些表象的東西就會逐漸的被抛除。
同時也開始設計的時候，沒有說一定要立刻就要設計出一個很強大的東西出來，對架構設計的能力也是在慢慢的演化和思考過程中提升的。
在解釋為什麼架構要像上面那副圖進行設計之前，我們首先來讨論一些之前項目問題：
對于資料通路層(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之前加上接口層來解耦。
這個圖和之前的第一個圖基本上是一樣的，隻是做了一修改，而且加上了之前談論中涉及的一些問題。
因為随着思考的深入，逐漸的發覺：資料源的來源可以很多—資料庫，普通文本，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