MVC模型 解決問題以及不足

解決問題

為了解決業務邏輯和界面渲染邏混在一起

MVC流程圖

2. 不足

由于 Model 對外直接暴露了 set 和 on 方法，導致 View 層可以隨意改變 Model 中的值，也可以隨意監聽 Model 中值的變化。這樣的設定最終會導致一個龐大的 Model 中 某個字段變化后，可能觸發無數個 change 事件。在這些 change 事件的回調中，可能還有新的 set方法調用，導致更多的 change 事件觸發。

MVC 的問題

FLUX模型解決問題以及不足

解決問題

• 相對于完全只使用 React實現項目： 應用的狀態數據只存在于 React組件之中， 每個組件都要維護驅動自己 渲染的狀態數據，單個組件的狀態還好維護，但是如果多個 組件之間的狀態有關聯，那就麻煩了。 比如子組件和父組件，父組件需要維護所有 子組件計數值的總和， 子組件和 父分別維護自己的 狀態，如何同步 父 和 子 狀態就成了問題， React 只提供了 props 方法讓組件之間通信，組件之間關系稍微復雜一點，這種方式就顯得非常笨拙。
• 相對于MVC數據模型: 解決MVC模型數據流混亂的形態，實行較為嚴格的 ‘單向數據流’的管理方式，MVC 最大的問題就是無法禁絕 View 和 Model 之 間的直接對話，對應于 MVC 中 View 就是 Flux 中的 View，對應于 MVC 中的 Model 的就 是 Flux 中的 Store，在 Flux 中， Store 只有 get方法，沒有 set方法，根本可能直接去修改 其內部狀態， View 只能通過 get方法獲取 Store 的狀態，無法直接去修改狀態，如果 View 想要修改 Store狀態的話，只有派發一個 action對象給 Dispatcher。

Flux模型

2. 不足

• Store之間存在明顯依賴關系
  在 Flux的體系中，如果兩個 Store之間有邏輯依賴關系，就必須用上 Dispatcher的 waitFor 函數。 父組件對 action類型的 處理，依賴于子組件已經處理過了。 所以，必須要通過waitFor函數告訴Dispatcher, 先讓 子組件處理這些 action對象，只有 子組件搞定之后 父組件才 繼續。
• 難以進行服務器端渲染
  如果要在服務器端渲染，輸出不是一個 DOM 樹，而是一個字符串，準確來說 就是一個全是 HTML 的字符串 。 在 Flux 的體系中，有 一 個全局的 Dispatcher，然后每一個 Store 都是一個全局唯 一 的對象，這對于瀏覽器端應用完全沒有問題，但是如果放在服務器端，就會有大問題 。和一個瀏覽器網頁只服務于一個用戶不同，在服務器端要同時接受很多用戶的請求， 如果每個 Store都是全局唯一的對象，那不同請求的狀態肯定就亂套了 。
• Store 混雜了邏輯和狀態
  Store 封裝了數據和處理數據的邏輯,當我們需要動態替換一個 Store 的邏輯時，只能把這個 Store 整體替換掉，那也就無法保持 Store 中存儲的狀態 ,例如: 在開發模式下，開發人員要不停地對代碼進行修改，如果 Store在某個狀態下引發了 bug，如果能在不毀掉狀態的情況下替換 Store 的邏輯，那就最好了，開發人員就可以不 斷地改進邏輯來驗證這個狀態下 bug 是否被修復了 。
  Redux模型解決問題以及不足

1. 原則以及解決問題

• 單一數據源
  在 Flux 中, 應用可以擁有多個 Store，往往根據功能把應用的狀態 數據劃分給若干個 Store 分別存儲管理 。如果狀態數據分散在多個 Store 中，容易造成數據冗余，這樣數據一致性方面就會出 問題。 雖然利用 Dispatcher 的 waitFor方法可以保證多個 Store之間的更新順序，但是這 又產生了不同 Store之間的顯示依賴關系，這種依賴關系的存在增加了應用的復雜度，容 易帶來新的問題 。 Redux 對這個問題的解決方法就是，整個應用只保持一個 Store，所有組件的數據源 就是這個 Store 上的狀態 。 這個唯一 Store上的狀態，是一個樹形的對象，每個組件往往只是用樹形對象上一部 分的數據 。
  Redux 和 Flux 之間最大的區別就是對 store/reducer 的抽象，Flux 中 store 是各自為戰的，每個 store 只對對應的 controller-view 負責，每次更新都只通知對應的 controller-view；而 Redux 中各子 reducer 都是由根reducer統一管理的，每個子reducer的變化都要經過根reducer的整合

Flux 中的 store 流程圖

Redux 中的 Reducer 流程圖

• 狀態是只讀的
  這一點和 Flux 的思想不謀而合，不同的是在 Flux 中，因為 store 沒有 setter 而限制了我們直接修改應用狀態的能力，而在 Redux 中，這樣的限制被執行得更加徹底，因為我們壓根沒有 store。 在 Redux 中，我們并不會自己用代碼來定義一個 store。取而代之的是，我們定義一個 reducer， 它的功能是根據當前觸發的 action 對當前應用的狀態(state)進行迭代，這里我們并沒有直接修 改應用的狀態，而是返回了一份全新的狀態。 Redux 提供的 createStore 方法會根據 reducer 生成 store。最后，我們可以利用 store. dispatch 方法來達到修改狀態的目的 。
• 狀態修改均由純函數完成
  純函數就是 Reducer, Redux 這個名 字 的前 三 個字母 Red 代表的就是 Reducer。 按照創作者DanAbramov的說法， Redux名字的含義是Reducer+Flux。 在 Redux 中，每個reducer 的函數 reducer(state , action), Flux 更新狀態的函數只有一個參數 action，因為狀態是由 Store 直接管理的，所以 處理函數中會看到代碼直接更新 state 。

總結

以上是生活随笔為你收集整理的mvc 事务层切换数据源_Mvc 与 Flux 与 Redux的一些思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。