使用Pull模型來實現前端的業務邏輯

本文首發於公衆號：符合預期的CoyPan

寫在前面

最近在總結本身在業務開發中遇到的問題，通過思考，發現了一個可能值得總結一下的點：使用Pull模型來實現業務邏輯。

背景

先無論什麼是Pull模型，咱們先來看下面的場景：

有一個異步操做A，A完成後，須要根據A返回的結果，再進行下一步的業務邏輯。

一種很常見的實現方式是：

A(res => {
  if(res === true) {
    // 業務邏輯M
  } else {
    // 業務邏輯N
  }
});
複製代碼

這種實現方式沒有什麼大問題。可是考慮這樣一個問題：

通過一段時間的迭代，業務邏輯M和業務邏輯N愈來愈複雜。這個時候，產品經理忽然要加一個前置條件：異步操做A完成後，若是返回值是true，那麼須要先進行一個異步操做B，若是B返回的一樣是true，再進行業務邏輯M。當這種狀況愈來愈多時，這個時候，代碼維護起來就比較麻煩了。

A(resA => {
  if(resA === true) {
    B(resB => {
      if(resB === true) {
        // 業務邏輯M
      }
    })
  } else {
    // 業務邏輯N
  }
});
複製代碼

我以前就遇到了這個問題。

####怎麼解決

要解決這個問題，其實很簡單。使用promise 和 await。

const resA = await PromiseA();
if(resA === false) {
  // 業務邏輯N
  return ;
}
const resB = await PromiseB();
if(resB === true) {
  // 業務邏輯M
}
複製代碼

改造後的代碼，咱們就能夠很方便的添加前置邏輯、和分支條件判斷了。

Pull模型

之因此await能夠解決上述問題，是由於：在我看來，await其實能夠看作是一個Pull模型。所謂Pull模型，實際上是來自消息中間件的一個概念。簡單來講，Pull模型就是：我須要什麼數據的時候，我再去拿。與之對應的，是Push模型：數據產生了，給你拿去用吧。

結合上面的代碼來看，咱們來看看Push模型和Pull模型的區別。

Push模型：

const asyncFn = function() {};
const callback = function(res) {
  if(res === true) {
    // ....
  }
};
asyncFn(callback);
複製代碼

上面的代碼，異步函數執行完成後，回調函數會當即執行。若是咱們想判斷異步函數執行的結果後，再去作邏輯，就必須再callback裏面寫代碼。異步函數直接把數據Push給了回調函數，回調函數會當即執行。

Pull模型：

const callback = function() {};
const asyncFn = async function() {};
const asyncRes = await asyncFn();
if(asyncRes === true) {
		callback();
}
複製代碼

上面的代碼，從異步函數中Pull了數據後，先進行判斷，而後再進入回調函數裏面的邏輯。

在我平時的業務開發中，會涉及到許多的異步操做，每個異步操做都涉及到時序性問題和條件分支問題。使用Pull模型，能夠很好的處理異步操做之間的時序問題，而且把代碼中的許多if else外置，每個函數專心實現一個業務邏輯，方便維護，且不易出錯。Pull模型能夠加強咱們對於異步操做的控制能力。

寫在後面

業務中使用await來書寫代碼，能夠解決許多問題，其根本緣由是await和回調函數在思想上就是不同的。本次總結，某種程度上加深了本身對於語言的理解，符合預期。