项目实战典型案例6——没有复用思想

Posted 2023-03-15 王卫——David

这里写目录标题

• 一：背景介绍
• • 反例
• 思路&方案
• • 反例一的优化思路和方案
  • • 反例一优化的模拟代码
  • 测试
  • • 优化之前的缺点与优化之后的优点
  • 反例二的优化思路和方案
  • • 反例二优化的模拟代码
    • 测试
    • 优化之前的缺点与优化之后的优点
• 四：总结

一：背景介绍

本篇博客是对项目开发中出现的没有复用思想的反例进行的总结并进行的改进。目的是将经历转变为自己的经验。通过博客的方式分享给大家，大家一起共同进步和提高。

反例

反例一解读：
这两个归根到底都是查询在线人员，并且返回的数据类型和结构都是一致的。我们完全有条件可以只写一个接口来实现这两个类似的功能。

反例二解读：
这里使用了mybatis动态SQL进行处理，但是对于course_id与class_id完全可以抽出来，作为公共的进行使用。

思路&方案

模拟代码的环境为：spring boot、 spring mvc 、mybatis、mysql

反例一的优化思路和方案

对于反例一的优化思路：两个查询在线人员的的接口我们可以使用一个接口进行实现，两个接口的区别主要是在于入参不一致，这里我们可以通过使用mybatis的动态SQL进行实现。这样我们由之前的两个接口的（两个controller、两个IService、两个ServiceImpl、两个mapper、两个sql）转变成了一个（controller、Iservice、ServiceImpl、mapper、sql）。

反例一优化的模拟代码

Controller层

 /*
     * @description:查询课程内容
     * @author: wangwei
     * @date: 2023/3/7 16:00
     * @param: [courseContent]
     * @return: java.util.List<com.wangwei.mvc.entity.CourseContentEntity>
     **/
    @PostMapping("/queryCourseContent")
    public List<CourseContentEntity> queryCourseContent(@RequestBody CourseContentEntity courseContent)
        return iCourseContentService.queryCourseContent(courseContent);
    

IService层

List<CourseContentEntity> queryCourseContent(CourseContentEntity courseContent);

ServiceImpl层

	@Resource
    CourseContentMapper courseContentMapper;
    /*
     * @description:查询课程内容
     * @author: wangwei
     * @date: 2023/3/7 15:57
     * @param: [courseContent]
     * @return: java.util.List<com.wangwei.mvc.entity.CourseContentEntity>
     **/
    @Override
    public List<CourseContentEntity> queryCourseContent(CourseContentEntity courseContent) 
        return courseContentMapper.queryCourseContentRecord(courseContent);
    

mapper层

//通用查询语句
    List<CourseContentEntity> queryCourseContentRecord(CourseContentEntity courseContentEntity);

mapper.xml

<select id="queryCourseContentRecord" resultMap="courseContentMap">
        SELECT id,course_assembly_id,assembly_content,create_time,created_id,created_by,update_time,updated_id,updated_by
        FROM  tar_course_content_info
        WhERE
        is_delete=0
        <if test="id != null"> and id = #id </if>
        <if test="courseAssemblyId != null">and course_assembly_id = #courseAssemblyId</if>
        <if test="assemblyContent != null">and assembly_content = #assemblyContent</if>
        <if test="createdBy != null">and created_by = #createdBy</if>
        <if test="updatedBy != null">and updated_by = #updatedBy</if>
        <if test="remark != null">and remark = #remark</if>
    </select>

测试

1.先查询所有的课程内容，不传入任何的参数

2.查询创建人为张有博的课程内容，传入参数createBy=“张有博”

优化之前的缺点与优化之后的优点

优化之前：

1. 由于没有进行复用导致代码大量重复，工作量是之前的2倍。对于后序的代码开发大大的增加了工作量。
2. 会照成对于单表的crud过多，例如没有采用复用的思想以及动态sql将会导致后序对于单表的查询过多，造成难以维护，维护量大。

优化之后：

1. 代码量小，复用性强，可以满足90%以上对于这张表的查询。
2. 维护维护成本低，只需要维护这一个查询接口

反例二的优化思路和方案

反例二的优化思路：将的course_id与class_id抽出作为公共数据使用。这样代码体现出代码的复用思想，以及维护量也小的多。

反例二优化的模拟代码

测试

优化之前的缺点与优化之后的优点

优化之前的缺点：代码冗余没有复用思想，比较不好维护。

优化之后的优点：将公共代码进行了复用，体现了复用思想，提高对于代码复用，代码维护。

四：总结

1.在设计之初应该想到如何设计接口如何设计，如何提高效率，如何到达复用强，维护成本低，扩展性强。是面向对象的设计还是面向过程的设计，最后选择一种复合当前项目的设计思想，并按照这个设计思想进行设计和开发。