MVC中的Controller的概念是否多餘？

1樓：

目前來說是的。MVC是歷史遺留產物，在微服務普及的時代已經是淘汰的分層理論了。

Controller層在以前的單體架構中承擔與UI對接的責任。然而在前後端分離的場景，微服務應該關注於服務本身而與檢視無關。目前的主流做法是使用api層替代controller層。

可能有人會提及Controller還能起到統一封裝返回體或者資料驗證，聚合各個service的作用。其實這種做法也是職責混亂的。資料驗證，聚合邏輯放到service本身即可。

另外api層只需要返回最原始結果的JSON，不需要額外封裝和對資料進行處理，資料處理是UI自己需要做的事。service只服務於業務而不是服務於檢視層。

2樓：一絲混亂

你說的莫不是後端的Controller類？

隨著業務越來越複雜，C也越來越龐大，自然而然的有人就想把C的邏輯抽象出來，於是MVC進化成了MVVM，VM層取代了C層絕大部分的功能。

問題來了，VM做的實在太好，以至於剩下的事基本不需要你手寫Controller實現了（不代表完全沒有了！）。你要把這些剩下的邊邊角角放到業務層中也問題不大。

但是VM做掉了一部分Controller的事不代表Controller就沒有了！就像乙個人爸媽幫他付了買房首付不代表這個房子不用錢。

至於web服務的Controller類，我感受大下來大部分時間就是封裝Service。不過有些操作放在Service挺奇怪的，比如乙個100個字段的表，業務需要100所以全拿出來了，但是前端只需要60個，為了提高效能所以在Controller中放到了乙個VO裡。

3樓：Hong HuaMin

挺好的問題。

在某些場景下，service直接對外提供服務是合適的，特別是controller只是原樣包裝service，顯得多餘的時候。

但是，多出來這層，提供了多個介面組合的能力，這樣service可以定位為較細或較低階的功能提供方，controller來解決共性需求和服務組合。

放在微服務場景下，controller就變形為服務組合和服務排程了。

套用一句老話，在軟體架構設計上，加一層來解決問題是老套又有效的法子

4樓：jswh

mvc是一種pattern，根據沒有銀彈理論每一種pattern都有自己的適用條件，所以你覺得這個多餘很可能只是你沒有遇到對應的情況。

至於mvc適用什麼情況，有很多資料，其他答主也說的很多，我乙個野生程式設計師更是不班門弄斧了。

另外，在規模小的時候，怎麼樣都行。

5樓：小亦

services：前進、後退、左轉、右拐、剎車、起飛、前進三......

controller：倒車入庫（前進、右拐、後退、右拐、前進、右拐、後退...）、馬路殺人（for(;1==1;) ）......

自行體會一下？

6樓：神們自己

這個問題好比：早中晚三餐中的晚餐是否多餘？

大部分人肯定會告訴你不多餘。

但是，這並不意味著人不吃晚飯就活不下去，也不意味著全世界所有人都一天三頓，更不意味著將來移民火星以後我們也必然會這麼吃。

在web早期提出MVC的時候，controller當然不多餘，對於目前主流的web依然不多餘。

但是，這並不代表MVC三駕馬車是缺一不可的，也不代表web只有MVC這一種玩法，更不代表未來MVC正規化一定是後端架構的主流。

比如，以前的網頁都是jsp、php、asp。而現在更流行：把V從後端移到前端，比如用vue、react做前端，後端就不需要V了。

controller早期的作用（典型如spring），一是接收使用者請求，二是處理業務邏輯。

業務邏輯也可以交給service，例如：後端只開乙個介面，前端一律請求json，後端根據json中的資訊來判斷，具體交給某個service處理。

這樣真的不需要C了，即使有，也是擺設。MVC變成model+service，完全可行。

所以我的觀點是：

曾經不多餘，現在有點多餘，將來很可能徹底多餘。

7樓：程式猿DD

不多餘。

Service負責領域相關的邏輯，比如：訂單建立、扣減庫存、增加積分，這樣乙個完整的業務相關的事務。關於Service層是否必要，之前寫過，可以看看之前的回答：

zhihu.com/question/433314934/answer/1620398175Controller負責執行Service邏輯之前，做好引數校驗、格式轉化等與業務無關的事情，在業務邏輯處理完畢之後，組織成前端要的格式返還。這一切關注的是與前端的對接，與業務並無關係。