00:02
我们来看一下,目前为止呢,我们已经完成了生成订单,调用统一下单API,并且呢通过返回的支付交易链接生成了二维码图片这样的一个完整的流程,那么此时此刻呢,用户就可以打开手机扫描我们生成的二维码进行微信支付了,那我们前面呢,还有一个步骤还需要完善一下,就是这个生成订单的过程,因为目前为止我们的订单呢,是生成在了内存当中,并没有实际的创建到数据库当中,所以呢,我们需要完善这个步骤。那么在真正的写后续的代码之前,我们先将我们的日志的级别呢,再修改为info,因为原来我们源码调试的时候的那个debug级别呢,他打印的日志呢,有点过于多。好,调整完了之后呢,我们来到我们的找到。微信配service,那么找到我们之前的统一下单的这个API调用的业务层的方法,我们找到我们生成订单这段代码,我们将要把这段代码呢移植到啊,我们存储数据库的代码当中,所以呢,我们将会在order info业务层当中呢,做一个生成订单的业务,那我们打开我们的order info。
01:18
好,我们在service里面呢,添加一个方法。呃,我们希望呢,这个方法呢,返回值就是一个新创建的订单,那我们给它起个名字呢,叫create order by ID,根据商品ID创建一个订单。我们给他一个参数,就是这个ID。接下来呢,我们生成它的实现类,那么在这个实现类当中呢,我们先用我们的商品ID查出我们的商品信息,所以呢,在前面这个位置呢,我们需要先注入我们的product map resource private product。
02:15
接下来呢,我们用。ID获取我们的商品信息。Select by ID传ID,然后得到一个商品对象,接下来呢,我们在生成订单,那么生成订单的过程呢,我们可以参考之前我们整个这个生成订单的过程。好,那么这一面呢,我们从当中获取。那订单的金额这边呢,我们也从当中获取。
03:05
好,接下来最后呢,我们将这个商品呢存入到数据库当中,所以我们可以用base map,第2INSERT order。好,这个base的意思呢,就是当前的这个map,当然了,你也可以写private order in。那这面呢,用order in for也可以啊,只不过呢,用base呢更简洁一些。那贝map的来源呢,就是这个MPL,我们点进去看一眼。
04:02
在这个里面呢,有一个base map,那的数据类型呢,就是这个M数据类型,而M这个数据类型呢,就是我们前面的。通用map也就是这个base map啊,这个接口的一个具体的实现了啊,所以在当前的这个order info啊这个场景下呢,我们对通用的实现呢是order,那因此呢,我们这个里面的base呢,就和order呢,其实呢是同一个意思,好。接下来呢,我们在这个方法的最后呢,返回一个。Order INF。然后呢,我们在微信配这个地方呢,对order。的生成进行一个调用。那么我们先引入依赖。
05:00
在这个位置。好,然后呢,我们用order info。来调用我们刚才写的方法。Create order by product ID,我们将ID传进去。那么呢,我们会得到一个order in,那接下来呢,我们就可以这个order in当中获取我们。调用统一下单API的过程当中需要的各种信息。我们重新启动一下服务器,来对刚才我们的这个代码呢做一个简单的测试。好,服务器已经启动成功了。我们来到我们的前端。
06:01
直接对确认支付的按钮进行点击。好,我们也成功的展示了这个二维码,我们来看数据库。好,数据库当中呢,也生成了相应的订单信息,并且呢,存储了我们在刚才的业务代码当中存储的这些信息,但是呢,现在有一个小小的问题,假设说用户点开这个二维码之后呢,他并没有去真正的实现支付。他就关闭了这个二维码,那接下来呢,他又想啊支付了,所以呢,他又点击确认支付,好又弹出这个二维码,那这样反复几次之后呢,我们会发现数据库当中。就会出现很多条记录,那么这种操作呢,其实在我们平时的工作场景当中呢,也很常见哈,那用户就是点一下是什么,然后他就关掉了啊,反复的去点。那这个过程当中呢,就会给我们的系统造成不少的压力。
07:02
首先呢,我们的系统当中呢,要创建很多个订单数据。其次呢,我们的系统呢,要在后端不断的。去在这个过程当中调用统一下单接口,所以我们可以对我们当前的这个业务流程呢再做一个优化。
我来说两句