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