一起談.NET技術，.NET 分布式架構開發實戰之三 資料通路深入一點的思考

　　前言：

　　首先，感謝朋友們對文章的支援，感謝大家，希望本系列的文章能夠真正的對大家起到一點幫助的作用。再次感謝大家。

　　大家也許想問，什麼時候出代碼，代碼一定會出的，我不想一上來就開始抛出一大堆的代碼，然後講解，架構的設計在思考的過程，思考到了，代碼也就水到渠成了。

　　上篇文章講述在設計之初，Richard所畫出的一些草圖，本篇對之前的草圖做了進一步的思考。

　　本篇的議題如下：

　　1、草圖的一些問題在哪裡

　　2、重審之前項目中資料層的問題

　　3、思維的一點突破

　　4、回首再看資料通路層

　　1.草圖的一些問題在哪裡

　　當Richard把草圖畫出來了之後，想到了另外的一個問題：在DAL資料層之間提供的那個接口層到底應不應該是Services Interface。其實這個接口層是普通的Interface層還是Services Interface，Richard也拿不定主意的，因為當初之是以要把這個接口層改為Services Interface，是因為在資料源提供者（Service Agent）那塊給了他靈感資料源可以使用遠端的Services。基于這個思想，是以Richard也考慮到了：

　　也許，現在設計的這個DAL，哪一天會作為服務給其他的程式提供資料也不說定。

　　雖然，這個問題對現在來說不是那麼的重要，但是在Richard的心裡，無法說服自己到底使用哪一種接口層（也許是Richard這個人的性格有關吧，一定要給個理由說服自己，但是這個理由又不能随随便便的糊弄自己）。

　　如果真的這樣設計，那麼資料層的做的事情就很多了，要很多的邏輯。而這些邏輯在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.GetTableT().InsertOnSubmit(entity)方法來插入任何的資料實體類。

　　但是就隻有這些不同條件的查詢方法很難統一，幾乎是每個不同的DAL都要去實作自己的一些特有的查詢方法。但是Richard認為把這些方法統一是有可能的，甚至是達到那種以不變應萬變的效果才好，帶着這個想法Richard開始進行很多的嘗試。

　　3. 思維的一點突破

　　Richard極力的在自己的腦海搜尋解決的方案，也翻閱自己之前下載下傳和買過的書籍，看看那些是否與查詢資料有關，隻要看到有查詢兩個字的章節，Richard就不會放過。也參看了.NET的一個知名開源Framework 的設計思想。

　　給了他提示的就是Fowler企業應用架構模式一書，書中提到的查詢對象(Query Object)， Richard參看了之後第一反應就是：确實不錯，但是太抽象了，沒有給出一些示例。

　　其實之前Richard在看這本書的時候，認為書的高度太高了，Richard幾次攻讀，都是深受打擊。是以，結果是Richard很敬畏這本書，但是還是想有朝一日能夠拿下它。現在書中就有了查詢對象的一些解決方案和實作，Richard硬着上了。

　　平時在思考的時候，自己站在一個高一點的角度看問題(現在是開發人員，但是開發人員在設計和開發的時候可以這樣想：如果我是架構的設計者,我會怎麼做？)，思維的高度上去了，機會到來的時候也就從容了。

　　查詢對象主要用途就是使得客戶程式可以構造各種的查詢，而且查詢中使用的都是與業務類有關的屬性，這就意味着，客戶程式不用了解資料庫的表名和列名。這種做法最直接的好處就是業務開發的人員不用知道資料庫的構造。

　　而且如果查詢對象的設計是以接口的形式出現，那麼靈活性就更加的大。例如，設計一個IQuery的查詢對象接口，然後，在架構中有兩個實作了IQuery接口的查詢對象，如LinqQuery, EFQuery,這兩個具體的查詢對象最終會被分别解釋為Linq和Entity Framework可以識别的語句，再通過Linq和Entity Framework去執行資料操作。在程式中就可以通過配置來決定使用哪種查詢對象和使用哪種資料通路技術。

　　越來越多的想法在Richard的腦海中出現，而随之帶來的問題也開始堆積。基本的思想是有了，但是實作起來那就得是另外的一回事了。怎麼把這些思緒理清，怎麼把這些理清的思緒變為代碼的實作，這個成為了擺在Richard面前最現實的難題。

　　但是不管怎樣，已經有了一點點的進展，記得當初考慮的時候還是頭腦一片空白，現在的想法一個接着一個，在思維上進步了。Richard覺得有點欣慰。

　　4.回首再看資料通路層

　　有了上面的思考，Richard再次審視了DAL，開始發覺：DAL其實就隻是一個存取資料和操作資料的地方，這就是DAL的主要功能。現在資料層的設計基本上已經可以實作了，而且可以做到以不變應萬變，不管BLL中對資料進行什麼樣的操作，在DAL層都可以用那個四種增，删，查，改的方法搞定。