上篇文章講述在設計之初，Richard所畫出的一些草圖，本篇對之前的草圖做了進一步的思考。
本篇的議題如下：
1.草圖的一些問題在哪裡
2.重審之前項目中數據層的問題
3.思維的一點突破
4.回首再看數據訪問層
1.草圖的一些問題在哪裡
當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之上的接口層，還是決定采用普通的接口。
2.重審之前項目中數據層的問題
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開始進行很多的嘗試。
3.思維的一點突破
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覺得有點欣慰。
4.回首再看數據訪問層
有了上面的思考，Richard再次審視了DAL，開始發覺：DAL其實就只是一個存取數據和操作數據的地方，這就是DAL的主要功能。現在數據層的設計基本上已經可以實現了，而且可以做到“以不變應萬變”，不管BLL中對數據進行什麼樣的操作，在DAL層都可以用那個四種增，刪，查，改的方法搞定。
出處：http://www.cnblogs.com/yanyangtian
