探索從 MVC 到 MVVM + Flux 架構模式的轉變

在業務中通常 MVVM 框架通常都會配合上數據狀態庫(redux, mobx 等)一塊兒使用，本文會經過一個小 demo 來說述爲何會引人數據狀態庫。

從 MVC 到 MVVM 模式提及

傳統 MVC 架構(如 JSP)在當今移動端流量寸土寸金的年代一個比較頭疼的問題就是會進行大量的全局重複渲染。可是 MVC 架構是好東西，其對數據、視圖、邏輯有了清晰的分工，因而前端 MVC 框架(好比 backbone.js) 出來了，對於不少業務規模不大的場景，前端 MVC 框架已經夠用了，它也能作到先後端分離開發單頁面應用，那麼它的缺陷在哪呢？

拿 backbone.js 說，它的 Model 對外暴露了 set 方法，也就是說能夠在不止一個 View 裏修改同個 Model 的數據，而後一個 Model 的數據同時對應多個 View 的呈現，以下圖所示。當業務邏輯過多時，多個 Model 和多個 View 就會耦合到一塊，能夠想到排查 bug 的時候會比較痛苦。

針對傳統 MVC 架構性能低(屢次全局渲染)以及前端 MVC 框架耦合度高(Model 和 View) 的痛處，MVVM 框架完美地解決了以上兩點。能夠參閱以前寫的 MVVM 框架解析之雙向綁定

only MVVM

假設有這麼一個場景，在輸入框中查詢條件，點擊查詢，而後在列表中返回相應內容。以下圖所示：

假設用 react 實現，思路大致是先調用查詢接口，調用成功後將獲取到的數據經過 setState 存進 list 中，列表顯示部分代碼以下：

const Decorate = (ListComponent) => class extends Component {
  constructor() {
    super()
    this.state = { list: [] }
  }

  componentDidMount() {
    fetch('./list.json')
      .then((res) => res.json())
      .then(result => this.setState({ list: result.data }))
  }

  render() {
    return (
      <ListComponent data={this.state.list} /> ) } } 複製代碼

接着往封裝的 Decorate 組件裏，傳入無狀態函數構建的 List 組件用來展現列表數據，代碼以下：

function List(props) {
  return (
    <div> {props.data.map(r => <p key={r.id}>{r.content}</p> )} </div>
  )
}
複製代碼

能夠看到 List 組件至關因而 View 層，而封裝的 Decorate 組件至關因而 Model 層。可是這麼作仍是把業務邏輯寫進了組件當中。而咱們指望的是能獲得一個純粹的 Model 層和 View 層。接着一塊兒看看 Flux 架構模式是如何解決這個問題的。

引人 Flux 架構模式

Flux 架構模式的 4 個重要組成部分以及它們的關係如上圖所示，下文會根據 dispatch，store, action, view 的順序逐步揭開 Flux 架構模式的面紗。

從 Flux 的源碼中能夠看出 Dispacher.js 是其的核心文件，其核心是基於事件的發佈/訂閱模式完成的，核心源碼以下：

class Dispatcher {
  ...
  // 註冊回調函數，
  register(callback) {
    var id = _prefix + this._lastID++;
    this._callbacks[id] = callback;
  }

  // 當調用 dispatch 的時候會調用 register 中註冊的回調函數
  dispatch(payload) {
    this._startDispatching(payload);
    for (var id in this._callbacks) {
      this._invokeCallback(id);
    }
  }
}
複製代碼

回顧下以前的目的：讓 Store 層變得純粹。因而定義了一個變量 comments 用來專門存放列表數據，在瞭解 Dispatcher 的核心原理以後，當調用 dispatch(obj) 方法時，就能夠把參數傳遞到事先註冊的 register 函數中，代碼以下：

// commentStore.js
let comments = []
const CommentStore = {
  getComment() {
    return comments
  }
}

dispathcer.register((action) => { // 調用 Dispatcher 實例上的 register 函數
  switch (action.type) {
    case 'GET_LIST_SUCCESS': {
      comments = action.comment
    }
  }
})
複製代碼

以及 action 中的函數以下：

// commentAction.js
const commentAction = {
  getList() {
    fetch('./list.json')
      .then((res) => res.json())
      .then(result =>
        dispathcer.dispatch({ // 調用 Dispatcher 實例上的 dispatch 函數
          type: 'GET_LIST_SUCCESS',
          comment: result.data
        }))
  }
}
複製代碼

可是彷佛少了點什麼，當 GET_LIST_SUCCESS 成功後，發現還缺乏通知到頁面再次調用 CommentStore.getComment() 的能力，因此再次引用事件發佈/訂閱模式，此次使用了 Node.js 提供的 events 模塊，對 commentStore.js 文件進行修改，修改後代碼以下：

let comments = []
const CommentStore = Object.assign({}, EventEmitter.prototype, {
  getComment() {
    return comments
  },

  emitChange() {
    this.emit('change')
  },

  addListener(callback) { // 提供給頁面組件使用
    this.on('change', callback)
  }
})

appDispathcer.register((action) => {
  switch (action.type) {
    case 'GET_LIST_SUCCESS': {
      comments = action.comment
      CommentStore.emitChange() // 有了這行代碼，也就有了通知頁面再次進行調用 CommentStore.getComment 的能力
    }
  }
})
複製代碼

剩下最後一步了，就是整合 store 和 action 進頁面中，代碼以下:

class ComponentList extends Component {
  constructor() {
    super()
    this.state = {
      comment: commentStore.getComment()
    }
  }

  componentDidMount() {
    commentStore.addListener(() => this.setState({ // 註冊函數，上面已經提過，供 store 使用
      comment: commentStore.getComment()
    }))
  }

  render() {
    return (
      <div> {this.state.comment.map(r => <p key={r.id}>{r.content}</p> )} </div>
    )
  }
}
複製代碼

小結

單純以 mvvm 構建應用會發現業務邏輯以及數據都耦合在組件之中，引入了 Flux 架構模式後數據和業務邏輯獲得較好的分離。可是使用 Flux 有什麼缺點呢？在下篇 《聊聊 Redux 架構模式》中會進行分析，下回見。

本文實踐案例已上傳至 stateManage

系列博客，歡迎 Star