DAO層與Business層之間的關係

最近工作了，也發現了自己曾經認識中的一些誤區，在 工作中慢慢的體會，慢慢的提升。

 

隨著系統越來越龐大，為了讓系統層次清晰，大家習以為常的為系統進行分層處理，現在很流行的也是三層架構，也就是常見的資料訪問層（DAO），商務邏輯層（Business），表現層（UI）。在表現層中又常常會採用MVC模式，即Model-View-Controller。針對著不同階層，在相互訪問操作中，用到了很多個物件，比如DTO（Data Transfer Object），BO（Business Object），PO（Persistence Object）等等。

 

一直以來，我採用三層架構，但卻不曾知道它真的用意（當然現在的認識也很淺顯）。直到在大四下學期中，在軟通動力實訓的時候，孫旭博老師給我們講DAO層的作用的時候，我一直以為DAO就是完成對象關係任務的對象。當然，DAO層完成的也的確是對象關係資料的相互轉換。但是，從松耦合的角度來說，把商務邏輯相關的資訊硬生生的寫到了DAO層，沒有使底層的架構與上層脫離關係，使得DAO層與Business層緊緊的貼住了。不知道大家在DAO層中寫沒寫過這樣或者類似的方法，就是登入時驗證使用者身份的方法。其實，這在個方法中，我們完成了一個DAO和一個商務邏輯，DAO就是到資料庫中根據使用者名稱和密碼擷取一個使用者，而商務邏輯就是，看看這個使用者是不是存在（當然，這個商務邏輯比較簡單）。因為簡單的邏輯讓這個設計並沒有什麼太大的問題，那麼當我們在一次中需要同時向三個表裡插入記錄的時候，那麼我們就要使用到事務，那麼我會在DAO層開始和關閉事務，大家想想這個是不是加大了DAO層的壓力。

這樣的DAO:

1. 獲得一個connection

2. 產生一個statement

3. 寫一句SQL，放入statement中

4. 執行statement

5. 關閉statement和connection

6. 返回結果

 

DAO層猶如一個管道，它只負責聯通就好了。讓它怎麼去通到商務邏輯處實現就好了。所以把事務加到商務邏輯層中，這樣呢，就需要我們對上面的DAO層對象做一下修改：

修改後的DAO:

1. 向DAO中注入一個connection

2. 生產statement

3. 寫SQL，放入statement

4. 執行statement

5. 返回結果

把statement和connection的關閉放到商務邏輯層中，這樣，我就可以在執行一個操作的過程中，操作多個DAO，而不用擔心它開啟和關閉，拒絕訪問等問題了。

 

最後我還想簡單說一下，在物件導向的編程中，有很多個物件，記起來挺麻煩的，如果理解了就比較容易了，因為它們都是與階層相互關聯的。

PO，是針對關係與對象映射的，用在DAO層訪問中

BO，是商務邏輯的對象，處理業務的時候使用的

DTO，其實這個對象是用在由伺服器跟用戶端互動的時候，傳輸資料時候用到的

 

 

PS:以上是個人在學習中的一點點小認識，比較淺薄，如果有些錯誤的地方，請大俠們指點，協助我糾正提高。