淺談Flux與MVC

1、Flux概述
Flux是Facebook用來構建用戶端的Web前端應用程序的體系架構，與其它形式化的框架相比，它更像是一個架構思想，用於管理和控制應用中數據的流向。這裏應用中的數據指包括但不限於來自服務端的數據頁面中view的一些狀態(如一個面板是展開仍是關閉)，臨時存儲在本地須要持久化到服務端的數據等。

好了，說了這麼多好像仍是一臉懵逼，不慌，接下來看看展開式。

2、MVC
在講述Flux以前，咱們看看以前傳統的MVC架構以及在web前端中的一些問題繼而思考Flux帶來的改變。MVC(Model-View-Controller)最早興起於後端，經過對應用程序複雜度的簡化使程序更加直觀和便於維護。後端程序MVC中View能夠看爲數據的呈現，Model爲數據的模型，Controller做爲程序的流程控制。

如今假設有這樣的場景，用戶想查看本身的profile頁面，可能會有這樣的流程：在頁面上點擊profile按鈕，接下來就是一個HTTP請求(/profile?username=jiavan) => Controller接收到這一請求並得到請求的內容username=jiavan而後告知Model須要jiavan的數據 => Model返回了jiavan的數據 => Controller獲得數據返回新的視圖，看下流程：

如今前端中又有這樣的場景：切換Menu中的Item，當前選中的Item顏色不一樣於其它顏色而且底部顯示對應Item的內容。

通常狀況下咱們會定義一個css class來做爲當前選中Item的樣式。當用戶點擊Item_A爲被點擊的元素新增高亮的class，其它兄弟元素移除該樣式，這裏的事件響應函數就是Controller，咱們會在這裏處理樣式修改邏輯，以及更新Model的數據，而後新的數據及樣式從新渲染界面。

這種VC<->M的形式在關係比較簡單的狀況下是比較清晰容易控制的，可是複雜的頁面上這樣的模式可能會變得很是混亂：

之因此變得混亂了，由於不少view都具有修改多個model的能力，這裏的單個修改行爲能夠稱之爲一個Action，一個Action的產生多是用戶行爲，或者一個Ajax請求須要渲染新界面。對比上面後端傳統MVC模式能夠發現：
後端中Action做爲一個URL請求，前端中多是一個事件；
後端中Action處理被集中在Controller中，而前端中是分散的。
那麼是否是能夠把前端中修改狀態即state的行爲(事件回調/Ajax)所有抽象成一種Action描述，而後交付到一處即Reducers來進行原子化處理，而後Reducer修改整個應用中惟一的一棵state tree即Store，最後經過state->view的機制來從新渲染?

3、Flux數據流框架
上面提到的幾個概念已經對Flux有了初步的瞭解，下面進入正題。相信有了解Flux的都應該看過下面這張著名的數據流圖：

Action能夠當作是修改Store的行爲抽象；
Dispatcher管理着應用的數據流，能夠看爲Action到Store的分發器；
Store管理着整個應用的狀態和邏輯，相似MVC中的Model。
因此Flux能夠被看做傳統MVC的改進而非顛覆。