我們的系列還在繼續，因為我們的專案還沒有完成。在上篇文章《目標模型和現實模型》中我們的小組解決的是需求問題，我們的系統要滿足的是目標模型，對目標模型的描述就是我們的需求定義。接下來我們需要考慮的是系統的實現。在討論之前，我們先回顧一下我們這個team的幾個角色：
專案經理：王濤
系統架構師：李帥
高階開發工程師：趙構
開發工程師：若干（我們在後面的章節中將逐步介紹）
系統設計或者架構是技術組來負責的，其組成如下：
組長：系統架構師 李帥
高階開發工程師 趙構
開發工程師，張昊。
李帥是乙個資深的開發工程師，在很多專案中做過技術負責人。根據過往的經驗，他提出系統應以三層架構為基礎進行設計。那麼三層架構又是什麼呢？
1、表現層（ui）：通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。
2、業務邏輯層（bll）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。
3、資料訪問層（dal）：該層所做事務直接運算元據庫，針對資料的增添、刪除、修改、查詢等。
這套架構在過往的專案中採用很多，相對也比較成熟，但問題也很多。**維護量很大，隨著時間的推移，也越來越不經濟。所以，李帥就此與王濤進行了深入討論。
李帥認為採用三層結構有如下：
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的復用。
6、擴充套件性強。不同層負責不同的層面，如petshop可經過簡單的配置實現sqlserver和oracle之間的轉換，當然寫好了也可以實現b/s與c/s之間的轉換
7、安全性高。使用者端只能通過邏輯層來訪問資料層，減少了入口點，把很多危險的系統功能都遮蔽了。
8、專案結構更清楚，分工更明確，有利於後期的維護和公升級
但王濤需要站在更高的層面來看待這個問題：
三層架構較之於不分層的架構明顯是進步了很多，對程式設計進行了分工，使得程式更加明晰。但這種三層架構仍然是一種面向過程（或者功能）的思維方式（雖然採用了物件導向的程式語言），業務邏輯大多寫在靜態方法中，這些靜態方法掛在乙個個偽物件下，很多相同的功能在不同的物件下重複，程式設計師為了完成某個功能，又難得在各個業務類下找這些方法，就會大量的寫一些他自己看得懂的業務方法。如此程式**程幾何級數增長，**的可維護性變得越來越差。這是程式設計師常說的「直上直下」。其根本原因是其不是真正的物件導向的思維方式，而只是傳統的面向過程方法在現代技術條件下的乙個變胎。
三層架構的是與非
我們的系列還在繼續，因為我們的專案還沒有完成。在上篇文章 目標模型和現實模型 中我們的小組解決的是需求問題，我們的系統要滿足的是目標模型，對目標模型的描述就是我們的需求定義。接下來我們需要考慮的是系統的實現。在討論之前，我們先回顧一下我們這個team的幾個角色 專案經理 王濤 系統架構師 李帥 高階...
什麼是三層架構？
三層架構 3 tier architecture 通常意義上的三層架構就是將整個業務應用劃分為 表現層 ui 業務邏輯層 bll 資料訪問層 dal 區分層次的目的即為了 高內聚，低耦合 的思想。1 表現層 uil 通俗講就是展現給使用者的介面，即使用者在使用乙個 系統的時候他的所見所得。2 業務邏...
什麼是三層架構
1 什麼是三層？三層架構 3 tier architecture 通常意義上的三層架構就是將整個業務應用劃分為 商場負責接待購買肉食品的顧客 商場從食品加工工廠批量購入食品 食品加工廠為商場提供肉食品 兔子在場負責提供原材料給食品加工廠 食品加工企業將整個企業業務分為三部分來實現，這樣做的好 處是 ...