背景

在开发业务系统中,经常会用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(***))))这样的结构,从而串起完整的业务逻辑。

小结

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