背景

在开发业务系统中，经常会用if else、 switch case等判断语句，根据不同逻辑执行对应的逻辑。但是随着业务逻辑越来越复杂，代码会难以扩展和阅读。

场景

假设负责一个售卖手机的电商网站，幸运用户无条件获得200元优惠券, 分别交纳500元定金和200元定金的两轮预定后（订单已在此时生成），现在已经到了正式购买的阶段。公司针对支付过定金的用户有一定的优惠政策。在正式购买后，已经支付过500元定金的用户会收到100元的商城优惠券，200元定金的用户可以收到50元的优惠券，而之前没有支付定金的用户只能进入普通购买模式，也就是没有优惠券

常规实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/**
 * @param {number} type - 1: 500元定金用户, 2: 200元定金用户, 3: 普通用户
 * @param {boolean} pay - true: 已支付, false: 未支付,降级到普通用户
 * @param {function} checkIsLuck - 查询是否新幸运用户
 */
var  getCoupon = function(type, pay, checkIsLuck) {
    checkIsLuck().then(function(isLuck) {
        if (isLuck) {
            console.log('得到200元优惠券');
        } else {
            if (type === 1) {
                if (pay) {
                    console.log('得到100元优惠券');
                } else {
                    console.log('无优惠券');
                }
            } else if (type === 2) {
                if (pay) {
                    console.log('得到50元优惠券');
                } else {
                    console.log('无优惠券');
                }
            } else {
                console.log('无优惠券');
            }
        }
    });
};

上面代码对于当前场景虽然能正常运行，但是想要维护和扩展无疑会很困难，任何改动也很可能破坏之前正常的逻辑。

中间件改造

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
var checkIsLuckUser = function(ctx, next) {
    return ctx.checkIsLuck().then(function(isLuck) {
        if (isLuck) {
            console.log('得到200元优惠券');
        } else {
            return next();
        }
    });
};

var pay500 = function(ctx, next) {
    if (ctx.type === 1 && ctx.pay) {
        console.log('得到100元优惠券');
    } else {
        return next();
    }
};

var pay200 = function(ctx, next) {
    if (ctx.type === 2 && ctx.pay) {
        console.log('得到50元优惠券');
    } else {
        return next();
    }
};

var normal = function(ctx, next) {
    console.log('无优惠券');
};

import compose from 'koa-compose';
const composed = compose([checkIsLuckUser, pay500, pay200, normal]);

composed({
    checkIsLuck() {
        return Promise.resolve(true)
    },
    type: 1,
    pay: false,
}); // 获得200元优惠券

composed({
    checkIsLuck() {
        return Promise.resolve(false)
    },
    type: 1,
    pay: false,
}); // 无优惠券

composed({
    checkIsLuck() {
        return Promise.resolve(false)
    },
    type: 1,
    pay: true,
}); // 获得100元优惠券

可以看到与之前的代码不一样，代码结构减少了嵌套，整体清晰了很多。
分拆成各个独立逻辑模块，去除耦合。
扩展新的逻辑只要定义一个新的逻辑模块，并插入队列里，同时也降低了代码改动的风险。

下面我们来看下中间件的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
function compose (middleware) {
  if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')
  for (const fn of middleware) {
    if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')
  }

  /**
   * @param {Object} context
   * @return {Promise}
   * @api public
   */

  return function (context, next) {
    // last called middleware #
    let index = -1
    return dispatch(0)
    function dispatch (i) {
      if (i <= index) return Promise.reject(new Error('next() called multiple times'))
      index = i
      let fn = middleware[i]
      if (i === middleware.length) fn = next
      if (!fn) return Promise.resolve()
      try {
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
      } catch (err) {
        return Promise.reject(err)
      }
    }
  }
}

把各个中间件组合放到队列里, compose方法内部把每个中间件包装成promise。
通过next方法递归调用队列里的中间件。
最终返回Promise.resolve(mid1(mid2(mid3(***))))这样的结构，从而串起完整的业务逻辑。

小结

实际上只要运用得当，中间件模式可以很好地帮助我们管理代码，逻辑之间的耦合性。中间件的数量和顺序是可以自由变化的，可以在运行时决定队列中包含哪些节点。