前言：

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

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

　　上篇文章講述在設計之初，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();        

        

        
        
      
        
NET技術：.NET 分布式架構開發實戰之三 數據訪問深入一點的思考，轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。