入行前我也覺得似乎沒必要分這麼多層，至少service層似乎沒什麼必要，controller層麼，畢竟是用來配合框架幫助我們解析request以及把我們的返回的資料封裝成response的，dao層呢，框架幫我們寫好了很多很實用的快速增刪改查的方法，也很實用。那麼中間這一點程式碼直接controller裡不就行了嗎，為什麼還專門要一個service層呢？

但是入行後我遇到了一個很基本的需求，就明白了service層確實還是有用的。需求是這樣子的，資料庫裡有公司（business），部門（deparment），和員工（employee）三個表。從名字就能看出來，這三個表是有依賴關係的。員工依賴於部門，部門依賴於公司。簡直就是真香打臉下場

什麼是三層架構？

三層架構是指：檢視層View、

業務邏輯層Servic

e、資料訪問層DAO。他們分別完成不同的功能。

View層：用於接收使用者提交請求的程式碼

Service層：系統的業務邏輯主要在這裡完成

DAO層：直接操作資料庫的程式碼

為了更好的降低各層之間的 耦合度（系統的複雜度，在

三層架構程式設計

中，採用面向抽象變成。即上層對下層的呼叫，是透過介面實現的。而下層對上層的真正服務提供者，是下層介面的實現類。服務標準（介面）是相同的，服務提供者（實現類）可以更換。這就實現了

層間解耦合

。

（發生在哪一層的變化，只需更改該層，不需要更改整個系統。層次清晰，分工明確，每層之間耦合度低——提高了效率，適應需求變化，可維護性高，可擴充套件性高）

Controller是管理業務（Service）排程和管理跳轉的。Service是管理具體的功能的。Controller只負責管理，而Service負責實施。

DAO只完成增刪改查，雖然可以1-n，n-n，1-1關聯，模糊、動態、子查詢都可以。但是無論多麼複雜的查詢，dao只是封裝增刪改查。至於增刪查改如何去實現一個功能，dao是不管的。

總結這三者，透過例子來解釋：

Controller像是服務員，顧客點什麼菜，菜上給幾號桌，都是ta的職責；

Service是廚師，action送來的選單上的菜全是ta做的；

Dao是廚房的小工，和原材料打交道的事情全是ta管。

相互關係是，小工（dao）的工作是要滿足廚師（service）的要求，廚師要滿足服務員（controller）轉達的客戶（view）的要求，服務員自然就是為客戶服務嘍。

加入你換成SpringWebFlux，

響應式程式碼

，這時候程式碼都是 Reactive Streams，如果程式碼組織好這3個層都可以在一個 Streams 中完成，這時候就沒有多大必要看重劃分這 3個層了。

另外，其他的非同步非阻塞web框架（node。js、vert。X），它們的黃金準則是不要阻塞事件迴圈——對應上面的就是控制器裡的程式碼不能是

同步阻塞

執行的。它們是事件驅動的，比如 vert。X 你要是想獲取一個 “100個回答”，你應該向

事件匯流排

地址 “GET_

100_ANSWERS

_ADDRESS”傳送一個事件，傳一個

回撥函式

，等事件響應後處理返回的結果寫入Response。這個事件匯流排地址上你應該註冊一個消費者，處理事件，返回 “100個回答“。

Web開發無論怎麼分層都是為了更好的組織程式碼，邏輯清晰、靈活、易閱讀、擴充套件性高。Go非面向物件可以做Web開發，Node。js 單執行緒非同步也可以做Web開發，Java同步阻塞可以做Web開發，Java非同步響應式也可以做Web開發，它們的程式碼組織方式也都不同。