【討論】MVC 在前端已死?
隨著越來越多的前端開發開勇單項資料流架構,有些人就開始考慮傳統的 MVC 是否還有未來?為了便於理解,我們首先分析一下前端架構的發展史。
在過去的 4 年裡,我看過許多 web 專案並花了大量的時間在前端架構或是為它整合一些框架。在 2010 年前,JavaScript(實現 jQuery 的語言)在傳統 web 應用中被廣泛用於 DOM 操作以及新增一些簡單的東西。人們並不關心架構方面的東西,一些 簡單的模組化方式 似乎已經足夠用於設計我們的程式碼了。
前端架構 vs 後端架構的討論隨著單頁應用這個概念的出現而爆發了,隨之出現的框架有比如:backbone 和 knockout。由於當時感念也都比較新,所以框架的設計者們不得不去其他地方獲取靈感,所以他們借鑑了一些來自後端架構中的實踐,而幾乎所有的知名後端框架都是傳統 MVC 的實現,由於其中的 一些小差異,也可以被叫做 MV*。
當 React.js 第一次以一個 View 層渲染庫出現在人們眼前時,它由於將 HTML 和 JavaScript 寫到一起的這種非直觀方式而被嘲諷。但人們忽視了 React 帶來的重要貢獻 —— 基於元件架構。React 並沒有發明元件的概念,但它讓元件開發更進一步。當 Facebook 在介紹 React 時將其稱為 “V in the MVC” 時,這一架構上的重大突破甚至連 Facebook 也忽視了。順便說一句,在 review 完一份 同時使用了 Angular 1.x 和 React 的程式碼庫 後,我直到現在還在做惡夢。
不過在 2015 年,隨著 Redux 和 RxJS 的使用,Flux 和函式式響應式程式設計(FRP)將我們從習慣上的傳統 MVC 的思維模式轉變到 單項資料流架構。
那 MVC 到底問題在哪裡?
當然,MVC 作為一個架構模式已經被開發使用了相當長的時間,同時也可以被使用與 web 開發。不要誤會,MVC 現在依然是後端開發中最好的模式,像 Rails 和 Django 等框架都很樂意使用這種模式。
但問題在於,MVC 在後端的使用的原則與分層方法與前端是不同的。更多精彩內容關注微信公眾號:全棧開發者中心(admin10000_com)
控制器與檢視耦合(Controller-View coupling)
從下圖可以看到檢視層和控制器在伺服器端是如何互動的,它們僅有兩個接觸點,都跨越了客戶端和伺服器端的邊界。
當我們將 MVC 放到客戶端,這就有問題了。控制器類似與我們所知的 code-behind。控制器是高度依賴檢視的(見下圖),在一些框架的實現中,它甚至是被檢視建立的(比如:ng-controller)。
另外,當你從單一職責原則(SRP)的角度考慮,這顯然不滿足。客戶端的控制器程式碼同時進行了 事件響應 和 業務邏輯。
胖模型(The fat Model)
考慮一下你在客戶端儲存的是何種模型。一方面我們有一些資料類似於 users 或 products 代表我們的應用狀態(Application State)。另一方面,我們需要儲存一些 UI 狀態,比如 Tab 是否顯示(_showTab_)或者當前選中的值(_selectedValue_)。
類似於控制器,模型也在違反單一職責原則(SRP),因為我們沒有一個好的辦法將 UI 狀態和應用狀態分開管理。
那什麼是適合元件的模型呢?
一個元件就是:檢視 + 事件響應 + UI 狀態。
下圖展示了我們如何真正的將 MVC 的模型分離成元件。然而紅線上方的部分,正是 Flux 嘗試去解決的:管理 應用狀態 和 業務邏輯。
隨著 React 以及基於元件的架構的流行,我們看到單項資料流在管理應用狀態方面的崛起。這兩者可以如此方便的配合在一起使用是因為它們完全覆蓋了原先的 MVC 的方式,並提供了一個對前端架構而言更好的關注點分離的方案。
不過不久後這就不止 React 了。如果你看過 Angular 2,你會發現它採取了完全相同的模式,不過你也可以用不同的方案來管理應用狀態,比如 ngrx/store。
現在真的沒有能做的更好的了,MVC 在起初就註定失敗。我們需要時間來探索,這是一個 5 年的發展過程才將前端架構發展到今天。想想看,5 年其實對一個最佳實踐的建立來說不算很長。更多精彩內容關注微信公眾號:全棧開發者中心(admin10000_com)
MVC 在起初是必要的,因為我們那時不知道在應用越來越龐大和複雜的時候,要如何組織我們的前端應用。我覺得它已經達到了起初的目的,而且也可以學習到,如果是從一個上下文(伺服器端)應用到另一個(客戶端)的時候,MVC 會是一個最佳實踐。
所以,未來將會是什麼?
對我們的前端應用來說,我不認為我們會很快回到傳統的 MVC 架構。隨著也來越多的開發者開始發現元件和單項資料流架構的優勢時,關注點會被放在如何基於這條道路建設更好的工具和三方庫。
那這類架構回事未來 5 年最好的解決方案嗎?很有可能是這樣,但是未來沒有東西是確定的。5 年前,沒有人能預測現在我們是如何寫應用的,所以現在我們也不敢這麼說。
相關文章
- MVC 在前端已死?MVC前端
- MVC模式已死MVC模式
- ChatGpt的出現,前端真的已死?ChatGPT前端
- 當我們在討論遊戲社群時,我們在討論什麼?遊戲
- 我們現在沒有討論的但有必要討論的模式模式
- 為什麼前端模型-檢視-控制器MVC會死?前端模型MVC
- Web已死Web
- SQL已死? - thenewstackSQL
- 彭博社:廉價智慧手機在中國已死
- CrunchBang Linux 已死!!!Linux
- 技術面試已死面試
- 資料庫已死資料庫
- Go-sword 專案更新 : Gitbook 文件已釋出 + 官方 QQ 群已建立 + 官網已支援討論留言GoGit
- 現在網路上很多人在討論AOP
- 在快取中檢索資料的方式大討論快取
- 熱點微前端Microfrontend的討論:谷歌AdWords是真實的微前端前端谷歌
- SetUnhandledExceptionFilter 的討論ExceptionFilter
- Spark已死?DBT會替代?Spark
- Web已死 Internet永生Web
- 執行緒池已死執行緒
- “Java已死”的簡史Java
- [iOS Monkey 討論帖] 整套新的 fastmonkey 討論iOSAST
- [技術討論]關於低耦合開發的討論
- 5G在工業中應用的討論
- 死磕 Elasticsearch 方法論Elasticsearch
- 討論著軟體測試發現到最後都不是在討論軟體次測試了
- 滬江前端由H5頁面引起的一場前端資料結構討論前端H5資料結構
- [譯] 討論 JS ⚡:文件JS
- httprunner 大佬討論群HTTP
- Ruby語言討論
- 當我討論遊戲是否“好玩”時我在說什麼?遊戲
- 討論:學習Java是否一定要學習前端常識麼?Java前端
- SQL 已死,但 SQL 將永存!SQL
- 【轉】Lisp 已死,Lisp 萬歲!Lisp
- 谷歌安全高管:密碼已死谷歌密碼
- Flash已死,但這些古老的Flash遊戲還在努力活著遊戲
- TRIZ理論在洗碗機設計中應用探討
- REST實戰討論組的文件資料在什麼地方?REST