MVC模型 解決問題以及不足

解決問題

為了解決業(yè)務(wù)邏輯和界面渲染邏混在一起

MVC流程圖

2. 不足

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

MVC 的問題

FLUX模型解決問題以及不足

解決問題

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

Flux模型

2. 不足

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

1. 原則以及解決問題

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

Flux 中的 store 流程圖

Redux 中的 Reducer 流程圖

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

總結(jié)

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

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