在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層。分別為：資料訪問層、業務邏輯層表示層。
在三層結構中有著很多的優點，例如：
1：開發人員可以只關注整個結構中的其中某一層；
2：可以很容易的用新的實現來替換原有層次的實現；
3：可以降低層與層之間的依賴；
4、利於各層邏輯的復用。
5：有利於標準化。
乙個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的介面，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。例如ui人員只需考慮使用者介面的體驗與操作，領域的設計人員可以僅關注業務邏輯的設計，而資料庫設計人員也不必為繁瑣的使用者互動而頭疼了。每個開發人員的任務得到了確認，開發進度就可以迅速的提高。
鬆散耦合的好處是顯而易見的。如果乙個系統沒有分層，那麼各自的邏輯都緊緊糾纏在一起，彼此間相互依賴，誰都是不可替換的。一旦發生改變，則牽一髮而動全身，對專案的影響極為嚴重。降低層與層間的依賴性，既可以良好地保證未來的可擴充套件，在復用性上也是優勢明顯。每個功能模組一旦定義好統一的介面，就可以被各個模組所呼叫，而不用為相同的功能進行重複地開發。
進行好的分層式結構設計，標準也是必不可少的。只有在一定程度的標準化基礎上，這個系統才是可擴充套件的，可替換的。而層與層之間的通訊也必然保證了介面的標準化。
但是三層結構中也有著一些遺憾的缺陷。
1：降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。
2：有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加乙個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的**。
三層 我眼中的三層結構
從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...
C 三層中的分頁
最近寫了乙個winform的管理系統，裡面的分頁同學推薦了幾種，感覺都不好用，比較麻煩，自己就找了乙個比較簡單的分頁，利用資料儲存過程來分頁。reate proc usp user pageindex int 1,頁碼預設值 pagesize int 2 頁容量預設值 asbegin select ...
三層結構解釋
所謂三層體系結構，是在客戶端與資料庫之間加入了乙個中間層，也叫元件層。這裡所 說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也 不僅僅有b s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一 臺機器上。三層體系的應用程式將業務規則 資料訪問 合法性校驗等工...