三層架構——Controller、Service、Dao
不僅是對代碼進行的邏輯分層。其真正的本質，是將業務、技術和數據剝離。搞業務的專心做業務，搞技術的專心搞技術，做數據存儲的專心做數據存儲。三方通過接口進行對接，任一部分重構，只要輸入和輸出接口的數據不受影響，就不對其他層造成影響。

三層架構是一種通用型的，面向功能的。具體架設可以結合企業業務的顆粒度進一步細分，增加層數。

我們先來看一下，對于一個項目，比較通用的流程都有什么？
1.接收請求、數據
2.數據合法性驗證
3.開啟事務
4.執行業務規則、邏輯、流程
5.數據存儲
6.事務結束

明顯，12可以封裝成一個模塊，346可以封裝，5作為一個模塊
劃分模塊后，就可以做異步了，程序不再是瀑布型，前端不必等業務邏輯全部完成

下面我們通過例子進一步理解

如何理解三層架構？

——服務員、廚子、倉儲模型

Controller——接口層（Web層）——服務員

Service——邏輯層——廚師

Dao——數據層——倉儲

為什么選擇三層架構？

https://www.bilibili.com/list/watchlater?oid=359096349&bvid=BV1PX4y1J7CC&spm_id_from=333.1007.top_right_bar_window_view_later.content.click
對于小公司，溝通成本低，一人多職，效率快響應快，這樣很容易做大。可是做大以后呢？項目不在是你一個人的事，需要大家一起來完成。那么，不同人有不同人的思維方式，有不同的編程習慣，而且溝通效率會直線下降，此時，我們就需要對項目進行架構，對編程方式進行規范，對輸入輸出做詳細要求。

和MVC有何不同，為什么有些地方叫Controller為視圖層？

MVC的本質思想是：輸入View、處理Model、輸出Controller。
其解決的問題是，將系統整體整體分類為三個部分，清晰，便于維護。
但事實上耦合性依然很高，各個功能之間的依賴關系很復雜。

三層架構的本質思想是：數據處理放一層，業務邏輯放一層，數據存儲放一層。
將業務和數據處理剝離，前端只需要對接Controller就好了，其余的兩部分無需因前端改變而改變。

事實上，在三層架構中，Controller充當的角色是網絡服務，相較于視圖層View，Controller層一般稱為接口處層或Web層。
它的職責是接收HTTP請求、解析參數、調用Service層處理業務、根據處理結果組裝響應（跳轉頁面或返回JSON等）。它扮演的是MVC模式中的協調者（Controller） 角色，而不是視圖（View）。

三層架構中View的概念被弱化，它不是一個層，而屬于一種技術實現，這個渲染過程通常發生在Controller層內部。
1.Controller返回一個邏輯視圖名，如 “user-list”
2.然后由視圖解析器（View Resolver），如Thymeleaf、FreeMarker去找到對應的模板，如 user-list.html并渲染
3.最終生成HTML返回給瀏覽器。

三層架構詳細拆解

必須堅持

接口層
堅決不寫任何業務邏輯代碼

邏輯層
不接受任何接口層的容器對象，如request、response、cookie、session。如果哪天我的接口層不采用Web，這些對象就通通沒有了
不處理任何數據存儲相關的SQL語句，不依賴任何數據層對象。這些對象只有連數據庫時候才會有，如果我換成緩存，它們也不復存在。

數據層
不處理任何業務邏輯代碼

功能拓展

Web層
如果我想要增加WebService、WebSocket兩個功能，我只需要在Web層中增加兩個模塊就可以了，不對另外兩層造成任何影響。
如果我想改用JDBC、JSF、JSP做前端，我只需要改Web層就可以了，不對另外兩層造成任何影響。

數據層
如果我們發現，某些數據的訪問頻度非常大，那么我們引入緩存就好了，只需要在數據層增加一個模塊，不對另外兩層造成任何影響。

進一步劃分

看見這個圖有沒有什么感覺？
沒錯，這是流水線的感覺，對于多線程，我們通過進一步細化流程，以提升效率。那么如果我們將小模塊聚合成服務，這樣就成了微服務架構的雛形。