这一块比较多也比较复杂主要分为一下几点
1.用户下单
2.订单支付(跳过实现)
3.历史订单查询
4.订单详细查询
5.再来一单
6.取消订单
一、用户下单
用户在挑选完菜品后需要将购物车的菜品提交下单，就是这么一个功能，接口文档如下：
这里专门设计一个DTO对象用于接收前端传递的参数，定义如下：
故在controller层直接调用service将接收到的DTO传过去，具体逻辑给到service实现！代码如下：
这里由于需要给前端返回订单号这类数据，所以同样定义了一个VO对象用于接收并且返回给前端。
service层的逻辑如何走呢，首先先看下有无异常条件需要判断，比如用户提交的时候没有地址，黑马还让校验购物车是否为空，其实我觉得这里应该是前端该做的事？为空应该都点不了提交这个按钮。
代码如下：
判断正常之后，需要生成订单并且插入订单的数据库中。生成订单数据以及插入代码如下：
这里的mapper层的insert有一个细节就是需要将主键自动生成的id写回orders这个对象中，因为后续可能需要。
插入订单之后，该订单还有一个order_detail表里面contain了具体点了什么菜品所以也需要插入这个表，由于要保持二者的事务一致性，所以别忘了加transactional。
这段代码就用上了之前插入得到的orderId，这里是一对多的关系其实，一个order对应多个detail！由于购物车和order detail差不多直接拷贝就好了。最后插入的是一个list，在mapper层用mybatis的foreach插入，代码如下：
做完插入之后，只需要清空购物车并且返回前端需要的数据就好了。代码如下：
这些前端需要的数据都是可以取到的，不用担心。
二、订单支付(跳过)
三、订单分页查询
这里的后端返回的有点多了，仔细分析一下，其实是order对象多了一个orderDetailList，也就是每个order它的detail也要跟着返回展示，细节图如下：
前端传递参数用的Query，这里可以直接对应接收，也可以用@RequestParam()，具体细节如下：
这里我们直接对应接收吧，代码如下：
分页查询的返回值就不多说了，本质就是一个total以及一个records，所以封装了一个pageResult。service的代码如下：
四.订单详细查询
跳过了，和第三条历史查询高度重合，简单的查出指定的订单以及detail返回就好了。
五、再来一单
再来一单的逻辑就是，我们对着一个订单点击再来一单，根据这个订单的下单内容重新填充我们的购物车。controller代码如下：
service的代码设计的语法自行解决吧：
六、取消订单
