写在前面
最近在总结自己在业务开发中遇到的问题,经过思考,发现了一个可能值得总结一下的点:使用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和回调函数在思想上就是不一样的。本次总结,某种程度上加深了自己对于语言的理解,符合预期。