三層架構的困惑：為什麼要分出資料訪問層

    今日閑來無聊逛起CSDN，看到一貼“三層架構的困惑：為什麼要分出資料訪問層 ”，本想為樓主釋疑，不過自己翻翻看這貼樓已高高，很多高人給出的見解真是經典，自己也不用再搶這點積分了，不過經典當然要收藏了，找來其中LoveCherry、doitnow2000(大海)、winternet(冬天) 三位的回複充充自己的部落格：

LoveCherry(論成敗，人生豪邁；大不了，重頭再來！^_^) ( ) 信譽：124
分層式結構究竟其優勢何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一書中給出了答案：
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的複用。

概括來說，分層式設計可以達至如下目的：分散關注、鬆散耦合、邏輯複用、標準定義。

一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的介面，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。例如UI人員只需考慮使用者介面的體驗與操作，領域的設計人員可以僅關注商務邏輯的設計，而資料庫設計人員也不必為繁瑣的使用者互動而頭疼了。每個開發人員的任務得到了確認，開發進度就可以迅速的提高。

鬆散耦合的好處是顯而易見的。如果一個系統沒有分層，那麼各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發生改變，則牽一髮而動全身，對項目的影響極為嚴重。降低層與層間的依賴性，既可以良好地保證未來的可擴充，在複用性上也是優勢明顯。每個功能模組一旦定義好統一的介面，就可以被各個模組所調用，而不用為相同的功能進行重複地開發。

進行好的分層式結構設計，標準也是必不可少的。只有在一定程度的標準化基礎上，這個系統才是可擴充的，可替換的。而層與層之間的通訊也必然保證了介面的標準化。

“金無足赤，人無完人”，分層式結構也不可避免具有一些缺陷：
1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此擷取相應的資料，如今卻必須通過中介層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在展示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的商務邏輯層和資料訪問層中都增加相應的代碼。

doitnow2000(大海) ( ) 信譽：100
剛接觸時，覺得分層太麻煩了，看似幾行代碼的功能卻分為業務層、資料訪問層...，當初覺得沒有必要，但是自從唯護了一個別人寫的系統後，（那個系統也沒有分層，屬於快速開發型的）發現分層極有必要，根據使用者需求的變化、自己對軟體的理解，我把那個系統用層來分離，現在唯護起來極來方便，

1、對系統的分層可以理解為對類的設計，我們知道設計的一個好的類，這個類是對它的形為負責，就是這個類應該做什麼，不應該什麼。分層也一樣的，業務層與資料訪問層所做負責的任務是不一樣的，它們之間的通訊用統一的介面。介面不變，內部實現可以變，（你愛用哪種方法、演算法實現都隨你）這樣層與層的鬆散就降低了。方便擴充，提高複用
2、分層會導致效能的降低、級聯修改（功能添加時）

winternet(冬天) ( ) 信譽：100
做的多了，自然就知道了分層的好處！不懂的，是因為還是沒有到達那個境界！好好看書和多實踐。