.NET 分布式架構開發實戰之三 資料通路深入一點的思考
前言：首先，感謝園子裡的朋友對文章的支援，感謝大家，希望本系列的文章能夠真正的對大家起到一點幫助的作用。再次感謝大家。
大家也許想問，什麼時候出代碼，代碼一定會出的，我不想一上來就開始抛出一大堆的代碼，然後講解，架構的設計在思考的過程，思考到了，代碼也就水到渠成了。
上篇文章講述在設計之初，Richard所畫出的一些草圖，本篇對之前的草圖做了進一步的思考。
本篇的議題如下：
1. 草圖的一些問題在哪裡
2. 重審之前項目中資料層的問題
3. 思維的一點突破
4. 回首再看資料通路層
系列文章連結:
<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>
當Richard把草圖畫出來了之後，想到了另外的一個問題：在DAL資料層之間提供的那個接口層到底應不應該是Services Interface。其實這個接口層是普通的Interface層還是Services Interface，Richard也拿不定主意的，因為當初之是以要把這個接口層改為Services Interface，是因為在資料源提供者(Service Agent)那塊給了他“靈感”——資料源可以使用遠端的Services。基于這個思想，是以Richard也考慮到了：也許，現在設計的這個DAL，哪一天會作為服務給其他的程式提供資料也不說定。
雖然，這個問題對現在來說不是那麼的重要，但是在Richard的心裡，無法說服自己到底使用哪一種接口層(也許是Richard這個人的性格有關吧，一定要給個理由說服自己，但是這個理由又不能随随便便的糊弄自己)。
Richard想到了之前在開發項目的時候，也确實曾經把其他公司提供的服務作為資料源的情況。當時的調用雖然隻是進行查詢，增加，删除，修改的簡單操作，但是很多的流程已經在服務提供者那邊定義好了，例如在發送一批貨物的時候，Richard隻是調用了服務接口的一個CreateProduct(Product product)方法，但是在伺服器那端卻做了很多的事情：計算庫存，生成訂單，選擇貨物供應商等等。這樣說來，如果現在Richard把DAL上面加上一個Services Interface層，那麼DAL或者其他的層就必須提供很多的邏輯操作，或者不一定是邏輯操作，還可以是資料格式驗證、身份驗證。
如果真的這樣設計，那麼資料層的做的事情就很多了，要很多的邏輯。而這些邏輯在BLL中進行才是比較好的選擇，想到這裡，Richard似乎開始明白：把Services Interface層放在BLL層之上。這樣就可以充分的利用BLL的邏輯驗證功能。是以DAL之上的接口層，還是決定采用普通的接口。
Richard在資料層DAL這塊花了大量時間來思考，其實是有原因的。在之前的項目中，資料層的設計顯得很臃腫，而且在Richard看來，這些代碼已經可以用一種比較通用的方式來寫，沒有必要寫那麼複雜的代碼。
例如，在EmployeeDAL中有以下的方法：
代碼
public Employee GetEmployeeById(string employeeId);
public Emplpyee GetEmployeeByName(string employeName);
public string GetEmployeePositionById(string employeeId);
public int GetEmployeeCount();
這樣寫，沒有錯。但是有一點引起了Richard的思考：DAL類中，很多的方法基本上都是查詢的方法，而Add, Update, Delete在很多的DAL類中形式都比較的統一，特别是在使用了Linq, Entity Framework之後，所有的資料實體類Add，Update, Delete方法幾乎是一樣的，如在Linq中可以使用DataContext.GetTable<T>().InsertOnSubmit(entity)方法來插入任何的資料實體類。
但是就隻有這些不同條件的查詢方法很難統一，幾乎是每個不同的DAL都要去實作自己的一些特有的查詢方法。但是Richard認為把這些方法統一是有可能的，甚至是達到那種“以不變應萬變的”效果才好，帶着這個想法Richard開始進行很多的嘗試。
Richard極力的在自己的腦海搜尋解決的方案，也翻閱自己之前下載下傳和買過的書籍，看看那些是否與查詢資料有關，隻要看到有“查詢”兩個字的章節，Richard就不會放過。也參看了.NET的一個知名開源Framework 的設計思想。
給了他提示的就是Fowler<<企業應用架構模式>>一書，書中提到的查詢對象(Query Object)， Richard參看了之後第一反應就是：确實不錯，但是太抽象了，沒有給出一些示例。
其實之前Richard在看這本書的時候，認為書的高度太高了，Richard幾次攻讀，都是深受打擊。是以，結果是Richard很敬畏這本書，但是還是想有朝一日能夠拿下它。現在書中就有了查詢對象的一些解決方案和實作，Richard硬着上了。
Richard認為：很多的事情不是等你的所有條件都具備才去做的，事情往往是在你還沒有準備好的情況下就已經發生了，凡事都有一個開頭，做架構也是這樣的，開始設計一個架構的時候，并且不是說明你已經完全的把所有技術都掌握了，完美了，肯定是有一個開始嘗試的過程。可能在開始設計的時候，漏洞百出，但是思維的周密性也是這樣慢慢的鍛煉出來的。
平時在思考的時候，自己站在一個高一點的角度看問題(現在是開發人員，但是開發人員在設計和開發的時候可以這樣想：如果我是架構的設計者,我會怎麼做？)，思維的高度上去了，機會到來的時候也就從容了。
Richard開始重新了解查詢對象。其實查詢對象就是在一定程度上隐藏了SQL語句，查詢對象是解釋器模式的一種應用,實際上查詢對象最後還是要解釋為SQL語句到資料庫中去執行的(不管在中間過程是如何一步步的操作這個查詢對象，因為資料庫現在隻是認識SQL，是以查詢對象最終還是要生成SQL語句)。
查詢對象主要用途就是使得客戶程式可以構造各種的查詢，而且查詢中使用的都是與業務類有關的屬性，這就意味着，客戶程式不用了解資料庫的表名和列名。這種做法最直接的好處就是業務開發的人員不用知道資料庫的構造。
而且如果查詢對象的設計是以接口的形式出現，那麼靈活性就更加的大。例如，設計一個IQuery的查詢對象接口，然後，在架構中有兩個實作了IQuery接口的查詢對象，如LinqQuery, EFQuery,這兩個具體的查詢對象最終會被分别解釋為Linq和Entity Framework可以識别的語句，再通過Linq和Entity Framework去執行資料操作。在程式中就可以通過配置來決定使用哪種查詢對象和使用哪種資料通路技術。
越來越多的想法在Richard的腦海中出現，而随之帶來的問題也開始堆積。基本的思想是有了，但是實作起來那就得是另外的一回事了。怎麼把這些思緒理清，怎麼把這些理清的思緒變為代碼的實作，這個成為了擺在Richard面前最現實的難題。
但是不管怎樣，已經有了一點點的進展，記得當初考慮的時候還是頭腦一片空白，現在的想法一個接着一個，在思維上進步了。Richard覺得有點欣慰。
有了上面的思考，Richard再次審視了DAL，開始發覺：DAL其實就隻是一個存取資料和操作資料的地方，這就是DAL的主要功能。現在資料層的設計基本上已經可以實作了，而且可以做到“以不變應萬變”，不管BLL中對資料進行什麼樣的操作，在DAL層都可以用那個四種增，删，查，改的方法搞定。
本篇就到這裡，謝謝各位！
下篇講述: .NET 分布式架構開發實戰之四 建構從理想和實作之間的橋梁
http://www.cnblogs.com/yanyangtian