小议mybatis plus相比传统mybatis手写SQL的好处

1、 发送通知需求：某一特定类别的商品，购买成功后需要发送通知给下单的客户，下单后默认通知状态为未发送，发送成功标记已发送。

2、 查询需求：查询某一用户的订单列表，列出订单信息和订单的商品信息。供给用户购买记录页面呈现使用。

（传统mybatis写法 和 mybatis plus 对比）

传统的mybatis做ORM映射工具并手写sql的时代，常规的写法基本上会是在dao层和servise层按此需求场景实现相应方法。

1、 发送通知需求：传统手写sql的时代dao层基本上会实现两个方法：

（1）“查询某一产品类别下尚未推送通知的订单”方法：用订单表关联产品表查询出某一产品类别下，尚未推送的订单

@Select(" SELECT o.id,o.order_code AS orderCode,o.notify_status AS notifyStatus,o.product_id AS productId 
          FROM product p  " +
        " INNER JOIN order o ON o.product_id=p.product_id " +
        " WHERE p.product_type_id=#{productType} and o.notify_status = 0 order by o.id  ")
List<Order> getNeedNotifyOrderBYProducType(@Param("productType") Integer productType);

（2）修改订单推送状态方法：

@Update("update order set notify_status=#{notifyStatus},update_time=NOW() " +
        "WHERE id = #{id}")
Integer updateStatus(@Param("id") Integer id,@Param("notifyStatus") Integer notifyStatus);

注：将sql写在xml文件里的方式同理 

然后发送通知这个需求基本就能实现了，写个定时任务每间隔多久运行一次，先取出待推送的订单，然后调用逐一调推送方法，再修改订单状态。（或者是批量的：先批量推送，然后批量修改订单状态）

但是随着项目持续开展，需求的不断演进，你会发现这两个方法的代码就只适用于这个场景而已，这里称之为“单一场景方法”。而且项目里这种单一场景的方法会越来越多、越来越多。打开dao层的文件一看“一堆方法”。今天订单关联商品写个join的关联查询语句，明天订单关联别的又写一个join的关联查询。今天修改订单推送状态写个update方法，明天修改订单别的状态又写个update方法。项目越来越臃肿，新人上手的可维护难度变得很大。也许有人会说，我们可以写一个统一的update方法，供service层调用。传进来实体类即可，根据主键ID修改相应数据。如下面：

this.orderDao.updateByPrimaryKey(order);

这样做隐患更大，因为我们上面的select语句是手写的sql ，字段都是手写的，因此如果需求改变了，订单表增加了几个字段，那么这些手写的select语句的sql就得从头到尾全都改一遍，否则这些sql查询出的实体数据，再执行updateByPrimaryKey方法就会把新增的字段修改为空。因此一个看似加个字段的简单需求，研发改动点会很多，测试的验证点也会很多。

2、 发送通知需求：mybatis plus时代，利用mybatis plus + Lambda表达式就能轻松实现，具体代码如下：

//第一步根据类别查询该类别下的商品
QueryWrapper<ProductEntity> productQueryWrapper = new QueryWrapper<>();
productQueryWrapper.eq("product_type_id", productTypeId);
List<ProductEntity> productList = productService.list(productQueryWrapper);

//第二步 用lambda表达式取出商品ID的集合
if(productList!=null && productList.size()>0){
    List<Integer> proudctIdList = productList.stream().map(p -> p.getProductId()).collect(Collectors.toList());

//第三步 查询该商品类别下的 未推送通知的订单列表
    QueryWrapper<OrderEntity> orderEntityQueryWrapper = new QueryWrapper<>();
    orderEntityQueryWrapper.in("product_id",proudctIdList);
    orderEntityQueryWrapper.eq("notify_status", StateTypeEnum.invalid.value());
    orderEntityQueryWrapper.orderByDesc("id");
    List<OrderMallEntity> orderList = orderService.list(orderEntityQueryWrapper);
}

最后处理完发送通知后，调用save方法修改订单状态

order.setNotifyStatus(StateTypeEnum.effective.value());
order.setUpdateTime(new Date());
orderService.saveOrderMall(order);

用mybatis plus QueryWrapper实现的好处就是：

（1） 全业务处理流程没有手写的SQL，dao层不会有过多的方法代码；

（2） 查询和修改方法由于都是基于实体映射的，因此即使日后扩展字段也不会有问题

（传统mybatis写法 和 mybatis plus 对比）

需求：查询某一用户的订单列表，列出订单信息和订单的商品信息。

1、 查询需求：传统手写sql的时代dao层基本上会实现一个方法：用订单表去关联产品表，查询出前端展示所需要的全部字段信息。

@Select(" SELECT o.id,o.order_code AS orderCode,o.notify_status AS notifyStatus,o.product_id AS productId " +
        "      ,p.product_name AS productName,p.product_type_id AS productType,p.product_img AS  productImg " +
        "      ,p.product_price AS  productPrice " +
        " FROM product p  " +
        " INNER JOIN order o ON o.product_id=p.product_id " +
        " WHERE  o.user_id=#{userId} " +
        " ORDER BY o.create_time desc ")
List<MallOrderDto> getOrdersByUserId(@Param("userId") Integer userId);

这种“单一场景”写法依然程序的健壮性很差，举个例子：某一天产品同事告诉你说咱们的商品需要增加一个“双十一”活动标签的概念。商品列表页、商品详情页、用户购买记录和订单详情页等等，只要涉及商品的地方，是“双十一”的商品都需要加上这个标签。一听到这个需求，第一意识就是需要在商品表里加个字段，然后将所有涉及产品的实体类扩展这个属性，并且将所有dao层的查询sql都修改一遍，加上这个字段。

2、 查询需求：mybatis plus时代，利用mybatis plus + Lambda表达式就能轻松实现，具体代码如下：

//第一步根据 用户查询该用户的订单列表
QueryWrapper<OrderEntity> orderEntityQueryWrapper = new QueryWrapper<>();
orderEntityQueryWrapper.eq("user_id",mallOrder.getUserId());
orderEntityQueryWrapper.orderByDesc("create_time");
List<OrderEntity> orderEntityList = orderService.list(orderEntityQueryWrapper);

//第二步 用lambda表达式取出商品ID的集合
if(orderEntityList!=null && orderEntityList.size()>0){
    List<Integer> proudctIdList = orderEntityList.stream().map(o -> o.getProductId()).distinct().collect(Collectors.toList());

//第三步 根据商品ID的集合查询商品列表
    QueryWrapper<ProductEntity> productQueryWrapper = new QueryWrapper<>();
    productQueryWrapper.in("product_id", proudctIdList);
    List<ProductEntity> productList = productService.list(productQueryWrapper);

//第四部将两个集合数据返回给前端
    respData.put("orderList",orderEntityList);
    respData.put("productList",productList);
}

这种实现方式，对于“双十一”商品标签这个需求，只需要数据库添加完字段，直接实体类扩展属性即可。所有使用到商品实体类做查询的接口自动就完成填充了。无需到dao层一个一个去修改select语句。

总结：如果不是特别复杂的sql，建议在程序的代码里尽量不要手写SQL，以免遗留一些后患。单表的增删改查建议强制要求用mybatis plus的无sql方式。简单的两个表关联查询的建议也用此文的lambda表达式的方式实现。虽然相比join多了一次数据库的交互，会稍微浪费点性能，但整体的代码可读性、可维护性和健壮性得到了很大提升。

文章的最后，将网上摘来的mybatis plus特性的一张图呈现给大家了解：

如需转载请与小助手（微信号：creditease_tech）联系。发现文章有错误、对内容有疑问，都可以通过关注宜信技术学院微信公众号（CE_TECH），在后台留言给我们。我们每周会挑选出一位热心小伙伴，送上一份精美的小礼品。快来扫码关注我们吧！

注：文章封面原图素材来源于网络，若有侵权请留言删除。

⏬点击“阅读原文”查看更多技术干货