架構模式mv*，flux

原文地址： https://github.com/HolyZheng/...

mvc

mvc分爲 model，view，controller三個部分

• model 模型層，管理應用程序的數據，以及對數據的一些處理方法，當它改變的時候，會通知它的觀察者
• view 視圖層，是model的可視化表示，一個view對應着一個model
• controller 控制器，是model和view之間的中介，當用戶操做view時，複雜更新model

mvc 幾點要注意的地方

1. view與controller之間是一個策略模式關係。 view把控制權移交給了controller，controller執行相關的應用邏輯，而且對來自view的數據進行預處理，調用model對應的接口。
2. controller操做model。model執行業務邏輯對數據進行處理，但不會直接操做view，對view時無知的。
3. view和model同步是經過觀察者模式進行，而同步操做是view本身請求model數據後對視圖進行更新。

缺點：

1. controller測試困難，由於同步操做是由view發出的。
2. view依舊依賴與model，難以組件化。

優勢：

1. 實現了關注點分離，簡化了總體的維護
2. 解耦了model和view，讓每一個模塊開發更加獨立

ps：關注點分離是指，各類技術負責本身的領域，不要混合在一塊兒，造成耦合

mvp

mvp分爲：model，view，presenter三個部分

• model 模型層，與業務相關的數據與操縱數據的方法
• view 視圖層，是model的可視化表示
• presenter 控制器，是view和model的中介

mvp與mvc的區別在於：view（視圖）與model（模型）之間有着更清晰的分離，view到model，model到view的數據同步都被轉移到了presenter中

mvp幾點要注意的地方

1. view再也不負責同步邏輯，而是由presenter負責。
2. view須要提供一組界面操做接口給presenter

優勢

1. 測試較爲方便，presenter對view的操做是經過接口進行的，可經過mock接口方式完成對presenter的測試
2. view可組件化，由於view不依賴與model，view對業務無知，只須要提供一系列接口給上層的操做，可作到高度可複用的組件。

缺點

presenter中除了應用邏輯以外，還有大量的view -》model，model -》view的手動同步邏輯，形成presenter比較重，維護起來困難。

mvvm

mvvm分爲view，model，viewmodel三部分

• model模型層，業務相關的數據
• view視圖層，是model的可視化表示，經過模板語法聲明式的渲染進dom
• viewmodel，介於model與view之間，經過數據綁定的方式實現view與model之間的同步（viewmodel，給view用的model加上相應的數據綁定方法和事件）

mvvm幾個關鍵點

1. viewModel，也就是「model of view」，視圖的模型，他的含義包括領域模型（domain model）和視圖狀態（state）
2. viewModel與presenter的區別，viewModel中有一個binder，即數據綁定來自動完成model與view之間的數據同步。

優勢

1. 提升了可維護性，雙向數據綁定機制解決了mvp中大量的手動view與model的同步問題
2. 簡化測試，減小了對view同步更新的測試

缺點

1. 過於簡單的頁面不適合
2. 大型應用中，視圖狀態較多，viewModel的構建和維護成本高
3. view模板中的數據狀態，沒法打斷點調試

flux

flux是什麼

flux是一種架構模式，它利用單向數據流的方式來管理數據。

這裏有幾個關鍵的概念

• view，視圖層
• action，視圖層發出的消息（動做）
• dispatcher，接收action，執行回調（派發器）
• store，存放應用的狀態，發生改變需提醒view更新（數據層）

注意

視圖層組件不直接修改應用狀態，只能出觸發action，應用狀態必須獨立出來放到store中同一管理，經過見監聽action來執行具體的狀態操做。

好處

1. 視圖層變得很薄，只包含渲染邏輯和觸發action
2. 要理解一個store能夠發生的變化，只須要看註冊的actions回調就行
3. 狀態變化經過action觸發，action經過dispatcher，因此每一次改變都從一個地方流過，有利於各類debug等操做。