這幾天學習三層架構和MVC，因為剛剛接觸，前幾天感到非常的困惑，從網上找了N多資料，看了N多人的看法，也浏覽了幾本書和視頻，這幾天稍微有了一點頭緒。但是每個人都有自己的看法，甚至有的人的看法在有些人看來都是錯誤的（我也覺得有的人的看法是錯誤的），下面談談我對他們的理解，希望大家可以指正。
首先說三層架構，即：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。每一層都有自己的職責，完成不同的任務，盡量減少不同層之間的交流，所有內聚性得到了大大的降低。下面是我對百度百科中的圖加工之後的，很形象的表達了三層之間的關系。它就像一個夾心餅干，最上層的餅干是一個外表，最下層的餅干起到了不可或缺的支撐作用，中間的奶油將上下層連接起來，完成它們的交互作用。
那麼三層的到底都是做什麼的呢？
1、表現層（UI）：通俗講就是展現給用戶的界面，即用戶在使用一個系統的時候他的所見所得。
2、業務邏輯層（BLL）：針對具體問題的操作，也可以說是對數據層的操作，對數據業務邏輯處理。
3、數據訪問層（DAL）：該層所做事務直接操作數據庫，針對數據的增添、刪除、修改、更新、查找等。
三層是將簡單的問題復雜化，使用三層做過項目的朋友都知道用三層架構的項目比不用三層的代碼量更加龐大，那還為什麼還要分層呢？
那就說說三層的優點：
1.解耦。上一層只依賴於下一層，如果測試下一層沒有問題，那麼問題就只可能出現在本層了。便於發現和改正BUG。
2.簡化復雜問題。就比如tcpip協議的四層模型或OSI七層模型，各層分工明確，將一個復雜問題簡化了。
3.便於系統維護/升級。各層間通過接口解耦，接口與實現分離，從而可以非常方便的替換掉實現，或者升級實現等。
4.邏輯復用。例如原來基於B/S開發的程序現在要改成C/S，那麼只要業務層的接口沒有改變，那麼業務層和數據層都可以直接復用。在如，只要數據訪問層接口不變，那麼使用便可以有對不同數據庫的實現。
5.便於團隊開發。只要各層接口在開發前規定好，那麼各層可以獨立開發，進化或維護。
6.方便部署。將各層開發成組件，則可以獨立部署。
其實分層也不一定只是分三層，如果你願意的話你可以分得更多，分層分得少得話就和不分一樣了，分得多的話軟件的復雜性相應的也會增加，對別人來說也就不好理解了，同樣也就不容易維護了。容易維護的產品必定是容易理解的，維護只是一個附帶的產物罷了。
多分層說了這麼多了，下面說說MVC吧。其實MVC和三層不是一種東西，很多朋友都將二者混在了一起，沒有真正的弄清二者之間的區別，它們確實也非常的相似，但是不是一種東西，就像讓你比較社會主義制度和歐洲聯盟一樣。
MVC是"Model-View-Controller"的縮寫，中文翻譯為"模型-視圖-控制器"。View就是界面視圖，所以我們容易和三層架構相混淆。三層架構為了各司其責，每個人都只顧自己的那點事，不關心別人是怎樣實現的，而它們之間相互聯系的部分誰都不願意干，所以在它們中間（UI層和BLL層之間）就應用到了MVC，就像下面老趙（微軟高級講師，趙劼）的這張圖所表達的含義一樣。
以上都是僅代表我個人的看法，非常誠懇的希望大家提出不同的看法和意見
摘自：許德鵬的專欄
