三層架構(3-tier architecture) 從開始到現在中間夾雜著考試已經拖拖拉拉好久了，現在打算把三層踏踏實實做一下總結，開始的時候思維非常亂，慢慢的總結也就是在整理自己的思緒吧。
下面這個圖是對三層的乙個巨集觀把握：
例子：如在飯店裡有服務員、廚師、採購員他們三者各司其職互不影響，這裡服務員起到和客戶進行互動的作用也就是表示層；廚師是把服務員的指令進行加工，同時告訴採購員需要的食品，相當於業務邏輯層；採購員是直接和食品打交道的，相當於資料訪問層。如果其中有一方不能工作，可以隨時找人替換而不影響工作進行。
按照邏輯上劃分：
顯示層ui：向使用者展現特定業務資料；採集使用者的輸入資訊和操作
業務邏輯層bll：從dal中獲取資料在ui層中顯示；從ui中獲取使用者指令和資料，執行業務邏輯，通過dal寫入資料來源db。起到承上啟下的作用。
資料訪問層dal：從資料來源中select、insert、update、delete資料。可以訪問資料庫系統、二進位制檔案、文字文件或是xml文件。
原理：
3個層次中，系統主要功能和業務邏輯都在業務邏輯層進行處理。
所謂三層體系結構，是在客戶端與資料庫之間加入了乙個「中間層」，也叫元件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也不僅僅有b/s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。三層體系的應用程式將業務規則、資料訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與資料庫進行互動，而是通過com/dcom通訊與中間層建立連線，再經由中間層與資料庫進行互動。
三層資料傳遞關係：
資料訪問層的類，直接訪問資料庫，實現基本記錄操作。
業務邏輯層的類，呼叫相關的資料訪問類，實現使用者所需功能。
介面層：部署控制項後，呼叫業務邏輯層的類，實現功能。
我的理解：
三層架構也就是把我們原來權力職責集於一身的制度（所有**都寫在一起）改變成不同層次各司其職（分層），每個層之間按照既定的制度和規則進行遊戲，其中如若出現意外或是中斷，可以立即更換部分零件而不影響全域性。
對比兩層和三層：
思想：高內聚、低耦合。
優點：
1.分工明確：開發人員可以只關注整個結構中的其中某一層。
2.角色替換：可以很容易的用新的實現來替換原有層次的實現。
3.低耦合性：可以降低層與層之間的依賴。
4.高內聚性：利於各層邏輯的復用。
5.有利於標準化。
缺點：
1.降低了系統的效能。因為多了中間層自然多了一些程式，降低系統效能。
2.有時會導致級聯的修改。如果某一層功能修改會導致其它層響應的修改。
當有資料訪問和業務邏輯時，當然大部分情況下都有，在系統是大中型應用程式時我們可以選擇用三層，它可以使設計階段有很清晰的思路，便於分工明確，便於後期的維護。如果系統過小，使用三層，反而會使設計繁瑣複雜。
1.找到三層之間的依賴傳遞關係
2.增加關係請求響應
3.建立資料庫
4.連線資料庫
注：實體類貫穿整體，是公共可以呼叫的模組，在下篇部落格中會詳細說明。
三層其實就是把我們平常生活中分工合作轉移到**中來，藝術源於生活高於生活，用心去發現。
初窺三層架構
即使到目前為止，我對三層的理解也是模糊的，發表下自己的拙見，希望大家指正。不是所有的程式都是適合使用三層的！很多出循著都會存在這樣的誤區，我學了半天三層發現對於我所寫的 沒有什麼用，反而讓 更複雜，費時費力，所以，我在論壇上看到不少關於三層的評價是 取之無味，棄之可惜 用了一段時間，感覺特別麻煩，就...
c mysql三層架構例項 三層架構例項
一 概要 這篇部落格，準備用乙個小demo來介紹應該實現三層架構。三層架構只是分層的一種經典形式，到底分幾層，要依具體情況而定，考慮到系統的複雜程度，和後期的可維護性，完全可以分四層，五層，甚至六層，七層。二 demo 1 實現語言 vb.net 2 需求 學校機房收費系統 中的乙個功能 操作員為學...
軟體架構 三層架構
三層系統的分層式結構 三層架構 3 tier architecture 通常意義上的三層架構就是將整個業務應用劃分為 區分層次的目的即為了 高內聚，低耦合 的思想。表現層 ui 通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。業務邏輯層 bll 針對具體問題的操作，也可以說是...