來(lái)源：鵝是程序猿

toutiao.com/i6763420080542843399

• 所以V層是否還有必要？

• 所以我認(rèn)為目前的多終端環(huán)境下，新的劃分方式如下：

---

標(biāo)題是不是有點(diǎn)聳人聽(tīng)聞，不過(guò)我并不是標(biāo)題黨。考慮到談?wù)撨@類(lèi)大而虛的東西（比如最好的語(yǔ)言）容易引起爭(zhēng)論和被噴，所以還請(qǐng)諸君帶著看戲而不是庭辯的心態(tài)來(lái)看待本文。

從webform過(guò)度到mvc，我曾經(jīng)驚嘆mvc革命性的變革。過(guò)去，在創(chuàng)建應(yīng)用時(shí)通常會(huì)按MVC各建一個(gè)文件夾，每個(gè)文件夾就是一個(gè)模塊。MVC三者的職責(zé)是這樣的：

1.Controller綁定到某個(gè)路由上，接著處理請(qǐng)求參數(shù)，然后創(chuàng)建在整個(gè)請(qǐng)求中可見(jiàn)的對(duì)象，并進(jìn)行一些業(yè)務(wù)邏輯上的工作。期間會(huì)從數(shù)據(jù)庫(kù)中構(gòu)造Model，也有可能新建/修改Model后將它們保存入數(shù)據(jù)庫(kù)。最后，Controller會(huì)通過(guò)View響應(yīng)用戶(hù)的請(qǐng)求，或者返回重定向的報(bào)文。基本上業(yè)務(wù)邏輯都是實(shí)現(xiàn)在Controller里面的。（下文為了闡述方便，都以“業(yè)務(wù)邏輯”特指Controller中的業(yè)務(wù)邏輯）

2.每個(gè)Model往往對(duì)應(yīng)數(shù)據(jù)庫(kù)的一個(gè)實(shí)體。Model類(lèi)除了裝數(shù)據(jù)之外，還提供了跟自己身份相關(guān)的一些方法，比如User類(lèi)提供authenticate方法以用于驗(yàn)證密碼。Model對(duì)象通常還會(huì)負(fù)責(zé)檢驗(yàn)構(gòu)造自己的參數(shù)是否正確。

3.View負(fù)責(zé)使用給定的參數(shù)渲染模板，并作為響應(yīng)返回給用戶(hù)。View一般是由該框架提供的模板語(yǔ)言寫(xiě)成。

但是用mvc做過(guò)N個(gè)項(xiàng)目之后，我越來(lái)越發(fā)現(xiàn)這種方式在某些方面有著不可忽視的弊端。尤其在現(xiàn)在多端共享數(shù)據(jù)的web環(huán)境，類(lèi)似于MVC這樣的組織方式已經(jīng)顯得過(guò)氣了，不同的客戶(hù)端需要不同的V層，很多時(shí)候pc端用v層，h5端，小程序段、App端都有自己的V層，然后數(shù)據(jù)通過(guò)Controller做成api的形式輸出數(shù)據(jù)。

所以V層是否還有必要？

最近的項(xiàng)目中，Controller直接就是輸出一個(gè)JSON數(shù)據(jù)，這么一來(lái)，傳統(tǒng)的View的扮演的戲份還剩多少似乎，我也一直思考如何如何在我們的項(xiàng)目組中進(jìn)行改進(jìn)。

過(guò)去，View通常由三部分組成：html代碼，控制流程語(yǔ)句，渲染時(shí)的上下文。如果提供的是JSON格式的模板，那么View的前兩部分基本不需要了，只需要渲染時(shí)的上下文。可是這么一來(lái)，為什么我還需要渲染一個(gè)JSON模板，目前的前端框架vue，React可以很方便的實(shí)現(xiàn)數(shù)據(jù)渲染。

所以我認(rèn)為目前的多終端環(huán)境下，新的劃分方式如下：

• View消亡了，PC端可以回歸原始的html頁(yè)面。

• Model分離成兩層，一層負(fù)責(zé)數(shù)據(jù)實(shí)體，另一層負(fù)責(zé)數(shù)據(jù)的訪(fǎng)問(wèn)。

• Controller分離成兩層，一層負(fù)責(zé)綁定路由，另一層負(fù)責(zé)業(yè)務(wù)邏輯。

以上是我個(gè)人對(duì)mvc的看法，大家可以討論或給出更好的方案。

總結(jié)

以上是生活随笔為你收集整理的为什么我不再推荐使用 MVC 框架？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。