.NET 分布式架構開發實戰之三 數據訪問深入一點的思考
核心提示：首先，感謝朋友對文章的支持，感謝大家，希望本系列的文章能夠真正的對大家起到一點幫助的作用。再次感謝大家。
.NET 分布式架構開發實戰之三 數據訪問深入一點的思考
前言：
首先，感謝朋友們對文章的支持，感謝大家，希望本系列的文章能夠真正的對大家起到一點幫助的作用。再次感謝大家。
大家也許想問，什么時候出代碼，代碼一定會出的，我不想一上來就開始拋出一大堆的代碼，然后講解，架構的設計在思考的過程，思考到了，代碼也就水到渠成了。
上篇文章講述在設計之初，Richard所畫出的一些草圖，本篇對之前的草圖做了進一步的思考。
本篇的議題如下：
1、草圖的一些問題在哪里
2、重審之前項目中數據層的問題
3、思維的一點突破
4、回首再看數據訪問層
1.草圖的一些問題在哪里
當Richard把草圖畫出來了之后，想到了另外的一個問題：在DAL數據層之間提供的那個接口層到底應不應該是Services Interface。其實這個接口層是普通的Interface層還是Services Interface，Richard也拿不定主意的，因為當初之所以要把這個接口層改為Services Interface，是因為在數據源提供者那塊給了他“靈感”——數據源可以使用遠程的Services。基于這個思想，所以Richard也考慮到了：
也許，現在設計的這個DAL，哪一天會作為服務給其他的程序提供數據也不說定。
雖然，這個問題對現在來說不是那么的重要，但是在Richard的心里，無法說服自己到底使用哪一種接口層。
Richard想到了之前在開發項目的時候，也確實曾經把其他公司提供的服務作為數據源的情況。當時的調用雖然只是進行查詢，增加，刪除，修改的簡單操作，但是很多的流程已經在服務提供者那邊定義好了，例如在發送一批貨物的時候，Richard只是調用了服務接口的一個CreateProduct方法，但是在服務器那端卻做了很多的事情：計算庫存，生成訂單，選擇貨物供應商等等。這樣說來，如果現在Richard把DAL上面加上一個Services Interface層，那么DAL或者其他的層就必須提供很多的邏輯操作，或者不一定是邏輯操作，還可以是數據格式驗證、身份驗證。
如果真的這樣設計，那么數據層的做的事情就很多了，要很多的邏輯。而這些邏輯在BLL中進行才是比較好的選擇，想到這里，Richard似乎開始明白：把Services Interface層放在BLL層之上。這樣就可以充分的利用BLL的邏輯驗證功能。所以DAL之上的接口層，還是決定采用普通的接口。
2.重審之前項目中數據層的問題
Richard在數據層DAL這塊花了大量時間來思考，其實是有原因的。在之前的項目中，數據層的設計顯得很臃腫，而且在Richard看來，這些代碼已經可以用一種比較通用的方式來寫，沒有必要寫那么復雜的代碼。
例如，在EmployeeDAL中有以下的方法：
代碼
| public Employee GetEmployeeById; |
没有评论:
发表评论