三層構架和 MVC的區別和理解

一、三層構架和 MVC 意思同樣麼？

Java WEB 開發中，服務端一般分爲表示層、業務層、持久層，這就是所謂的三層架構：

一、表示層負責接收用戶請求、轉發請求、生成數據的視圖等；

二、業務層負責組織業務邏輯；

三、持久層負責持久化業務對象；

這三個分層，每一層都有不一樣的模式，即架構模式，以下圖：

最開始學 Java WEB 的時候，認爲 MVC 就是 Java 裏的三層架構，後來又認識到這樣的想法不對，昇華到認爲 MVC 是表示層的架構模式，表示層最經常使用的架構模式就是MVC。

這個話題其實十年前，Java 社區都已經討論爛了，真是悲劇，由於後來我還一直認爲：MVC 意思是模型層、視圖層、控制器層，其實哪裏來的這麼多層？是否是還要來個Service 層、DAO 層、DTO 層？

這是不正確的認識……

MVC 就是 M——模型、V——視圖、C——控制器，而層的英文是 tier（物理上）、或者 layer（邏輯上）。即，層有相似計算機網絡那種從上到下的遞進關係，而模型、視圖、控制器沒有從上到下的明確關係。

MVC 並不是誰創造的理論，它只是被賦予一個世界通用的名字，任何有經驗，有追求的程序員即便徹底不知道 MVC 這個東西，也都會走向 MVC。

故個人認知最後昇華爲：MVC 是模型，視圖，控制器，和三層架構不是一個東西。它們更不是什麼視圖層，模型層，控制器層，沒有這個說法，但凡這麼說的，要麼就是習慣了這麼說，要麼就是理解錯誤。

二、MVC 是表示層的架構模式

Java  WEB 的三層架構是一個設計上的分層思想，三層架構設計中的每層都有本身的架構模式，架構模式就是每層的套路，相似傳統武術裏的套路，每一層都有本身的套路，這個套路就是所謂的架構模式。

表示層最經常使用的套路就是 MVC ，它不是軟件設計模式，這是不一樣的概念，硬要扯上關係，只能說 MVC——這個企業級開發架構中的表示層經常使用的架構模式包含了多個軟件設計模式的思想。

好比，MVC 架構模式是多種設計模式的複合，也能夠說是複合設計模式的體現：

一、Model  和 Controller  之間是策略模式 ，表示對一樣的數據能夠有不一樣的處理策略（算法），參考：接口的經常使用用法都有什麼？策略設計模式複習總結 

二、Model 和 View 之間是觀察者模式，View 表示觀察者， Model 是主題，View 訂閱了主題（Model）……參考：發佈訂閱/回調模型的核心技術——觀察者模式複習總結 

MVC 在實際環境中有不少的變體和改進，只要體會其中思想，無需嚴格跟概念相同，好比常見的有經典 MVC 和 Web 開發的 MVC 架構模式。

登陸用戶也就是瀏覽器客戶端（不少時候以計算機的角度看程序更容易理解程序）是和控制器——Controller 交互的，而客戶端看到的是 View ，它看不到 model。

客戶端裏；輸入用戶名，密碼 》發送http請求 》觸發 Controller 調用 Model 的數據校驗接口，Model 校驗不符合，觸發 Controller 選擇登陸失敗的 View 返回給客戶端，用戶就看到一個登陸失敗的提示，以後客戶端裏輸入正確的密碼，重複以前的操做，如 model 校驗 success，則觸發 Controller 去作對應策略的選擇，再調用 model 的登陸接口來請求登陸（策略設計模式），model 和數據存儲系統交互，完畢以後觸發 controller 更新 view（觀察者設計模式）……用戶就看到登陸成功的提示了。

三、業務層的架構模式

業務層的架構模式有事務腳本模式、領域模型模式等等，企業應用中最關鍵的顯然是業務層。

事務腳本模式是最簡單，最容易掌握的，若是開發團隊面向對象設計能力通常，並且業務邏輯相對簡單，業務層通常都會採用事務腳本模式，由於簡單

若是業務邏輯複雜，用事務腳本模式就很不明智了，簡單點講，就是違背了單一職責設計原則，Service 類成爲萬能的上帝，承擔了太多職責……

3.一、事務腳本模式

事務這裏表明表示層的一個請求，所謂腳本就是一個方法，所謂事務腳本就是將一次請求封裝爲一個方法，所謂事務腳本模式，就是將業務層的對象分爲三類，其中：

一、Service 類封裝業務流程，或者說是純粹的界面上的業務流程

二、DAO 類只負責對數據的操做，也就是封裝對持久層的訪問

三、DTO（Student）類封裝業務的實體對象，負責業務層內數據的傳輸流動

各個對象之間的關係，按照下圖的方式組織起來——簡單的學生管理業務層UML類圖：

service類：包含一個 service 接口和對應的 service 接口的實現類，dao 相似，而 dao 和 service 是一種聚合關係，service 類聚合了 dao 類。

對於聚合：聚合是關聯關係的一種特例，他體現的是總體與部分、擁有的關係，即 has-a 的關係，此時總體與部分之間是可分離的，他們能夠具備各自的生命週期，部分能夠屬於多個總體對象，也能夠爲多個總體對象共享；

好比計算機與cpu、公司與員工的關係等，表如今代碼層面，和關聯關係是一致的，只能從語義級別來區分；

DTO類：在 dao 和 service 中都有關係，屬於依賴關係。即：dao，service 依賴 DTO 類來傳輸數據對象

依賴：是類 A 使用到了另外一個類 B，而這種使用關係是具備偶然性的、臨時性的、很是弱的，可是 B 類的變化會影響到 A；

好比某人要過河，須要借用一條船，此時人與船之間的關係就是依賴，表如今代碼層面爲：類B（DTO）做爲參數被類A（dao，service）在某個 method 使用，這就是所謂業務邏輯的組織方式

3.二、爲何要用 Service 接口和 DAO 接口？

還得回到最基本的面向對象設計原則上去，有三條與此相關：

一、開閉原則

二、依賴倒轉原則

三、里氏替換原則

依賴倒轉原則：高層不依賴於低層，兩者都依賴於抽象，也就是面向接口編程。用 Service 接口是讓表示層不依賴於業務層的具體實現。用 DAO 接口是讓業務層不依賴於持久層的具體實現

有了這兩個接口，Spring IOC 容器才能發揮做用

舉個例子，用 DAO 接口，那麼持久層用 Hibernate，仍是用 mybatis，仍是 JDBC，隨時能夠替換，不用修改業務層的 Service 類的代碼。dao，service 使用接口的意義就在此。

四、持久層的架構模式

持久層的架構模式有入口模式（MyBatis、JDBC 是入口模式的典型實踐）、數據映射器模式（Hibernate 是數據映射器架構模式的典型實踐）等等。篇幅有限，很少說。

通常來講，框架  >  架構模式  >  設計模式  >  設計原則

打個比方：

一、Hibernate 是一個持久層框架，是數據映射器架構模式的具體實現，實現時用到了工廠模式等軟件設計模式，體現了依賴倒轉、開閉、里氏替換等等設計原則。

二、SpringMVC 是一個表示層 MVC 架構模式的實現框架，是 MVC 架構模式的一種實現，實現時用到……設計模式等，體現了……設計原則，諸如此類。

前面總結了那麼多，貌似有些跑。