|
.NET 分布式架構(gòu)開發(fā)實戰(zhàn)之三 數(shù)據(jù)訪問深入一點的思考
前言：
首先，感謝園子里的朋友對文章的支持，感謝大家，希望本系列的文章能夠真正的對大家起到一點幫助的作用。再次感謝大家。
大家也許想問，什么時候出代碼，代碼一定會出的，我不想一上來就開始拋出一大堆的代碼，然后講解，架構(gòu)的設(shè)計在思考的過程，思考到了，代碼也就水到渠成了。
上篇文章講述在設(shè)計之初，Richard所畫出的一些草圖，本篇對之前的草圖做了進(jìn)一步的思考。
本篇的議題如下：
1).草圖的一些問題在哪里
2).重審之前項目中數(shù)據(jù)層的問題
3).思維的一點突破
4).回首再看數(shù)據(jù)訪問層
1.草圖的一些問題在哪里
當(dāng)Richard把草圖畫出來了之后，想到了另外的一個問題：在DAL數(shù)據(jù)層之間提供的那個接口層到底應(yīng)不應(yīng)該是Services Interface。其實這個接口層是普通的Interface層還是Services Interface，Richard也拿不定主意的，因為當(dāng)初之所以要把這個接口層改為Services Interface，是因為在數(shù)據(jù)源提供者(Service Agent)那塊給了他“靈感”——數(shù)據(jù)源可以使用遠(yuǎn)程的Services�；谶@個思想，所以Richard也考慮到了：
也許，現(xiàn)在設(shè)計的這個DAL，哪一天會作為服務(wù)給其他的程序提供數(shù)據(jù)也不說定。
雖然，這個問題對現(xiàn)在來說不是那么的重要，但是在Richard的心里，無法說服自己到底使用哪一種接口層(也許是Richard這個人的性格有關(guān)吧，一定要給個理由說服自己，但是這個理由又不能隨隨便便的糊弄自己)。
Richard想到了之前在開發(fā)項目的時候，也確實曾經(jīng)把其他公司提供的服務(wù)作為數(shù)據(jù)源的情況。當(dāng)時的調(diào)用雖然只是進(jìn)行查詢，增加，刪除，修改的簡單操作，但是很多的流程已經(jīng)在服務(wù)提供者那邊定義好了，例如在發(fā)送一批貨物的時候，Richard只是調(diào)用了服務(wù)接口的一個CreateProduct(Product product)方法，但是在服務(wù)器那端卻做了很多的事情：計算庫存，生成訂單，選擇貨物供應(yīng)商等等。這樣說來，如果現(xiàn)在Richard把DAL上面加上一個Services Interface層，那么DAL或者其他的層就必須提供很多的邏輯操作，或者不一定是邏輯操作，還可以是數(shù)據(jù)格式驗證、身份驗證。
如果真的這樣設(shè)計，那么數(shù)據(jù)層的做的事情就很多了，要很多的邏輯。而這些邏輯在BLL中進(jìn)行才是比較好的選擇，想到這里，Richard似乎開始明白：把Services Interface層放在BLL層之上。這樣就可以充分的利用BLL的邏輯驗證功能。所以DAL之上的接口層，還是決定采用普通的接口。
2.重審之前項目中數(shù)據(jù)層的問題
Richard在數(shù)據(jù)層DAL這塊花了大量時間來思考，其實是有原因的。在之前的項目中，數(shù)據(jù)層的設(shè)計顯得很臃腫，而且在Richard看來，這些代碼已經(jīng)可以用一種比較通用的方式來寫，沒有必要寫那么復(fù)雜的代碼。
例如，在EmployeeDAL中有以下的方法：
代碼
public Employee GetEmployeeById(string employeeId);
public Emplpyee GetEmployeeByName(string employeName);
public string GetEmployeePositionById(string employeeId);
public int GetEmployeeCount();
出處：博客園
責(zé)任編輯：bluehearts
上一頁 下一頁 .NET 分布式架構(gòu)開發(fā)實戰(zhàn)(三) [2]
◎進(jìn)入論壇網(wǎng)絡(luò)編程版塊參加討論
|
第 1 頁 .NET 分布式架構(gòu)開發(fā)實戰(zhàn)(三) [1]
第 2 頁 
