我們的系列還在繼續，因為我們的項目還沒有完成。在上篇文章《目標模型和現實模型》中我們的小組解決的是需求問題，我們的系統要滿足的是目標模型，對目標模型的描述就是我們的需求定義。接下來我們需要考慮的是系統的實現。在討論之前，我們先回顧一下我們這個Team的幾個角色：

項目經理：王濤

系統架構師：李帥

高級開發工程師：趙構

開發工程師：若干（我們在后面的章節中將逐步介紹）

?

系統設計或者架構是技術組來負責的，其組成如下：

組長：系統架構師 李帥

高級開發工程師 趙構

開發工程師，張昊。

李帥是一個資深的開發工程師，在很多項目中做過技術負責人。根據過往的經驗，他提出系統應以三層架構為基礎進行設計。那么三層架構又是什么呢？

三層架構(3-tier application) 通常意義上的三層架構就是將整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即為了“高內聚，低耦合”的思想。

?

? ? ? ?1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。

　　2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。

　　3、數據訪問層（DAL）：該層所做事務直接操作數據庫，針對數據的增添、刪除、修改、查找等。

?

這套架構在過往的項目中采用很多，相對也比較成熟，但問題也很多。代碼維護量很大，隨著時間的推移，也越來越不經濟。所以，李帥就此與王濤進行了深入討論。

李帥認為采用三層結構有如下：

1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利于標準化；
5、利于各層邏輯的復用。
6、擴展性強。不同層負責不同的層面，如PetShop可經過簡單的配置實現Sqlserver和oracle之間的轉換，當然寫好了也可以實現B/S與C/S之間的轉換
7、安全性高。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了。
8、項目結構更清楚，分工更明確，有利于后期的維護和升級

但王濤需要站在更高的層面來看待這個問題：

三層架構較之于不分層的架構明顯是進步了很多，對編程進行了分工，使得程序更加明晰。但這種三層架構仍然是一種面向過程（或者功能）的思維方式（雖然采用了面向對象的編程語言），業務邏輯大多寫在靜態方法中，這些靜態方法掛在一個個偽對象下，很多相同的功能在不同的對象下重復，程序員為了完成某個功能，又難得在各個業務類下找這些方法，就會大量的寫一些他自己看得懂的業務方法。如此程序代碼程幾何級數增長，代碼的可維護性變得越來越差。這是程序員常說的“直上直下”。其根本原因是其不是真正的面向對象的思維方式，而只是傳統的面向過程方法在現代技術條件下的一個變胎。

?? ? ?本文轉自陳革 51CTO博客，原文鏈接：http://blog.51cto.com/chenge/1061810，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的三层架构的是与非的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。