為什麼不推薦使用MVC?

條件：多終端環境使用共同的背景業務層與資料層

分析：

從webform過度到mvc，我曾經驚歎mvc革命性的變革。過去，在建立應用時通常會按MVC各建一個檔案夾，每個檔案夾就是一個子產品。MVC三者的職責是這樣的：

1.Controller綁定到某個路由上，接着處理請求參數，然後建立在整個請求中可見的對象，并進行一些業務邏輯上的工作。期間會從資料庫中構造Model，也有可能建立/修改Model後将它們儲存入資料庫。最後，Controller會通過View響應使用者的請求，或者傳回重定向的封包。基本上業務邏輯都是實作在Controller裡面的。（下文為了闡述友善，都以“業務邏輯”特指Controller中的業務邏輯）

2.每個Model往往對應資料庫的一個實體。Model類除了裝資料之外，還提供了跟自己身份相關的一些方法，比如User類提供authenticate方法以用于驗證密碼。Model對象通常還會負責檢驗構造自己的參數是否正确。

3.View負責使用給定的參數渲染模闆，并作為響應傳回給使用者。View一般是由該架構提供的模闆語言寫成。

但是用mvc做過N個項目之後，我越來越發現這種方式在某些方面有着不可忽視的弊端。尤其在現在多端共享資料的web環境，類似于MVC這樣的組織方式已經顯得過氣了，不同的用戶端需要不同的V層，很多時候pc端用v層，h5端，小程式段、App端都有自己的V層，然後資料通過Controller做成api的形式輸出資料。

是以V層是否還有必要？

最近的項目中，Controller直接就是輸出一個JSON資料，這麼一來，傳統的View的扮演的戲份還剩多少似乎，我也一直思考如何如何在我們的項目組中進行改進。

過去，View通常由三部分組成：html代碼，控制流程語句，渲染時的上下文。如果提供的是JSON格式的模闆，那麼View的前兩部分基本不需要了，隻需要渲染時的上下文。可是這麼一來，為什麼我還需要渲染一個JSON模闆，目前的前端架構vue，React可以很友善的實作資料渲染。

是以我認為目前的多終端環境下，新的劃分方式如下：

View消亡了，PC端可以回歸原始的html頁面。

Model分離成兩層，一層負責資料實體，另一層負責資料的通路。

Controller分離成兩層，一層負責綁定路由，另一層負責業務邏輯。

歡迎大家談談自己的看法，以上為個人工作思考，大家可結合自己工作實際項目進行分析與留言。