三層（多層）架構

就拿B/S開發說起。最初的ASP直接把數據庫訪問代碼寫在頁面上。整個網站就是幾個頁面。數據訪問、業務控制、界面顯示全都在一個文件里。這種設計可以理解為一層架構。因為它沒有分層的概念。在這樣的開發模式下，同樣的邏輯代碼經常出現在多個地方。當有相似的功能需要實現時，直接拷貝代碼到另一個地方，然后修改。如果遇到系統升級或業務規則發生變化，必須找遍整個系統并作調整。這樣的設計不僅工作量大，而且不利于維護。往往一個程序員必須熟悉數據訪問和業務規則，同時還得精通頁面的編寫，因為要寫完一個功能就必須把這些內容全部寫在頁面上。JSP程序員在開發一個功能時會寫兩樣東西jsp和JavaBean。JaveBean封裝了數據訪問和業務邏輯，jsp頁面調然JavaBean的接口，然后將數據顯示在頁面上。這樣如果有多個頁面需要用到相同的業務規則只需調用同一個JavaBean封裝好的接口即可。如果修改了業務規則直接修改JavaBean而不用到每個頁面上去尋找相同的代碼。同時也使得業務邏輯實現人員可以和界面開發人員分工合作。這種設計可以理解為兩層架構（表現層、數據訪問+業務邏輯）。隨著編程技術的發展，人們發現不同的業務規則里可能會用到相同的數據。如果按照原來的設計方式同樣存在許多重復的代碼在JavaBean里。所以后來就將數據訪問和業務邏輯再次細分。形成了表現層+業務邏輯層+數據訪問層這種架構。當然，隨著技術的發展和系統復雜程序的增加，一個系統還可能存在其它的“層”，如：權限驗證層、對象緩存層等。

三層（多層）架構的出現，使得程序編寫的代碼得以重用，程序員之間可以更好地分工合作，程序架構更加清晰并易于維護。但三層（多層）架構并非適合于所有的項目開發。原先獲取一個數據只需直接從數據庫查詢出來即可。用到了三層（多層）架構后還得先通過業務邏輯層，然后數據訪問層才可以得到。原來一個類或一段代碼就可以完成的操作變成了好幾個類協作才能完成。如果項目規模并不大，采用這樣的多層架構就像殺雞用牛刀一樣反而不順手了。所以，多層架構適用于需要協同開發且具有一定規模或業務較復雜的系統。同時由于分了多層，一個接口的變化可能會引起多層接口的修改。