隨着愈來愈多的前端開發開勇單項數據流架構,有些人就開始考慮傳統的 MVC 是否還有將來?爲了便於理解,咱們首先分析一下前端架構的發展史。react
在過去的 4 年裏,我看過許多 web 項目並花了大量的時間在前端架構或是爲它整合一些框架。在 2010 年前,JavaScript(實現 jQuery 的語言)在傳統 web 應用中被普遍用於 DOM 操做以及添加一些簡單的東西。人們並不關心架構方面的東西,一些 簡單的模塊化方式 彷佛已經足夠用於設計咱們的代碼了。git
前端架構 vs 後端架構的討論隨着單頁應用這個概念的出現而爆發了,隨之出現的框架有好比:backbone 和 knockout。因爲當時感念也都比較新,因此框架的設計者們不得不去其餘地方獲取靈感,因此他們借鑑了一些來自後端架構中的實踐,而幾乎全部的知名後端框架都是傳統 MVC 的實現,因爲其中的 一些小差別,也能夠被叫作 MV*。github
當 React.js 第一次以一個 View 層渲染庫出如今人們眼前時,它因爲將 HTML 和 JavaScript 寫到一塊兒的這種非直觀方式而被嘲諷。但人們忽視了 React 帶來的重要貢獻 —— 基於組件架構。React 並無發明組件的概念,但它讓組件開發更進一步。當 Facebook 在介紹 React 時將其稱爲 「V in the MVC」 時,這一架構上的重大突破甚至連 Facebook 也忽視了。順便說一句,在 review 完一份 同時使用了 Angular 1.x 和 React 的代碼庫 後,我直到如今還在作惡夢。web
不過在 2015 年,隨着 Redux 和 RxJS 的使用,Flux 和函數式響應式編程(FRP)將咱們從習慣上的傳統 MVC 的思惟模式轉變到 單項數據流架構。編程
那 MVC 到底問題在哪裏?redux
固然,MVC 做爲一個架構模式已經被開發使用了至關長的時間,同時也能夠被使用與 web 開發。不要誤會,MVC 如今依然是後端開發中最好的模式,像 Rails 和 Django 等框架都很樂意使用這種模式。c#
但問題在於,MVC 在後端的使用的原則與分層方法與前端是不一樣的。後端
從下圖能夠看到視圖層和控制器在服務器端是如何交互的,它們僅有兩個接觸點,都跨越了客戶端和服務器端的邊界。服務器
當咱們將 MVC 放到客戶端,這就有問題了。控制器相似與咱們所知的 code-behind。控制器是高度依賴視圖的(見下圖),在一些框架的實現中,它甚至是被視圖建立的(好比:ng-controller)。
另外,當你從單一職責原則(SRP)的角度考慮,這顯然不知足。客戶端的控制器代碼同時進行了 事件響應 和 業務邏輯。
考慮一下你在客戶端存儲的是何種模型。一方面咱們有一些數據相似於 users 或 products 表明咱們的應用狀態(Application State)。另外一方面,咱們須要存儲一些 UI 狀態,好比 Tab 是否顯示(_showTab_)或者當前選中的值(_selectedValue_)。
相似於控制器,模型也在違反單一職責原則(SRP),由於咱們沒有一個好的辦法將 UI 狀態和應用狀態分開管理。
那什麼是適合組件的模型呢?
一個組件就是:視圖 + 事件響應 + UI 狀態。
下圖展現了咱們如何真正的將 MVC 的模型分離成組件。然而紅線上方的部分,正是 Flux 嘗試去解決的:管理 應用狀態 和 業務邏輯。
隨着 React 以及基於組件的架構的流行,咱們看到單項數據流在管理應用狀態方面的崛起。這二者能夠如此方便的配合在一塊兒使用是由於它們徹底覆蓋了原先的 MVC 的方式,並提供了一個對前端架構而言更好的關注點分離的方案。
不過不久後這就不止 React 了。若是你看過 Angular 2,你會發現它採起了徹底相同的模式,不過你也能夠用不一樣的方案來管理應用狀態,好比 ngrx/store。
如今真的沒有能作的更好的了,MVC 在起初就註定失敗。咱們須要時間來探索,這是一個 5 年的發展過程纔將前端架構發展到今天。想一想看,5 年其實對一個最佳實踐的創建來講不算很長。
MVC 在起初是必要的,由於咱們那時不知道在應用愈來愈龐大和複雜的時候,要如何組織咱們的前端應用。我以爲它已經達到了起初的目的,並且也能夠學習到,若是是從一個上下文(服務器端)應用到另外一個(客戶端)的時候,MVC 會是一個最佳實踐。
因此,將來將會是什麼?
對咱們的前端應用來講,我不認爲咱們會很快回到傳統的 MVC 架構。隨着也來越多的開發者開始發現組件和單項數據流架構的優點時,關注點會被放在如何基於這條道路建設更好的工具和三方庫。
那這類架構回事將來 5 年最好的解決方案嗎?頗有多是這樣,可是將來沒有東西是肯定的。5 年前,沒有人能預測如今咱們是如何寫應用的,因此如今咱們也不敢這麼說。