框架结构基础

RuoYi 框架学习知识点补充

总体补充

（1） controller
控制层

相当于MVC的C层，controller通过service的接口来控制业务流程，也可通过接收前端传过来的参数进行业务操作。

（2） model 
数据模型层

相当于MVC的M层，存放实体类，与数据库中的属性值基本保持一致。

（3） service
业务逻辑层

主要是针对具体的问题的操作，把一些数据层的操作进行组合，间接与数据库打交道（提供操作数据库的方法）。

要做这一层的话，要先设计接口，在实现类。

（4） mapper
数据存储对象

相当于DAO层，mapper层直接与数据库打交道（执行SQL语句），接口提供给service层。

---

mapper.xml

    <select id="selectPurchasingIndustryList" parameterType="PurchasingIndustry" resultMap="PurchasingIndustryResult">
        <include refid="selectPurchasingIndustryVo"/>
        <where>
            <if test="status != null "> and status = #{status}</if>
            <if test="content != null  and content != ''"> and content = #{content}</if>
            <if test="name != null  and name != ''"> and name like concat('%', #{name}, '%')</if>
            <if test="manager != null  and manager != ''"> and manager = #{manager}</if>
        </where>
    </select>

对于xml而言，可以使遍历的对象编程组件 :

    <sql id="selectPurchasingIndustryVo">
        select id, create_time, status, update_time, content, name, manager from purchasing_industry
    </sql>

<sql> 和 <include>

<sql>封装SQL语句简写select 和 insert语句, <include>根据id在查询和新增语句中调用<sql>标签中的语句

<sql>标签中的id 唯一对应<include>标签中的refid

---

mapper.java

public List<PurchasingIndustry> selectPurchasingIndustryList(PurchasingIndustry purchasingIndustry);

为什么是List?

变体Set：SetList，在SetList，保存一个状态(listEnable)，调用get(index)方法时，如果listEnable=false，为该SetList建立一个List，用set元素填充List个元素，用List随机访问。如果listEnable=true，直接随机访问list。调用add和delete的时候设置listEnable为false，回收list的空间。这样就有所有的优点，但是存储空间是原来的2倍
变体List：建立一个足够大的List，这个list只能插入不能删除，一旦数量到达上限，新建一个list二倍容量的list把元素考过去。这样只有不能删除一个缺点，其他优点都有。

List是有顺序的 可重复的
Map是通过键值对进行取值的    key和value是一一对应的

相当于DAO层，mapper层直接与数据库打交道（执行SQL语句），接口提供给service层。

---

service.java

public List<PurchasingIndustry> selectPurchasingIndustryList(PurchasingIndustry purchasingIndustry);

主要是针对具体的问题的操作，把一些数据层的操作进行组合，间接与数据库打交道（提供操作数据库的方法）。

---

Impl.java

    @Autowired
    private PurchasingIndustryMapper purchasingIndustryMapper;

    /**
     * 查询【请填写功能名称】列表
     *
     * @param purchasingIndustry 【请填写功能名称】
     * @return 【请填写功能名称】
     */
    @Override
    public List<PurchasingIndustry> selectPurchasingIndustryList(PurchasingIndustry purchasingIndustry)
    {
        return purchasingIndustryMapper.selectPurchasingIndustryList(purchasingIndustry);
    }

Springboot中为什么需要采用Service+ServiceImpl的结构

为解决移植性问题而产生的套路
2005年以前的大多数项目都是直接在业务处理层的Service类中嵌入JDBC代码，这就使得这个Service类与数据库紧藕合，在换一种数据库的情况下，就要修改Service类中的sql。 根据软件设计的开闭原则，软件应该对修改关闭、对扩展开放。 因此，那时聪明的程序员就把这个Service类设计成一个接口，使控制层只依赖这个接口，于是就有了controller+service+serviceImpl；这样，当某天这个应用要跑在其它数据库上时，就而只需要增加一个serviceImpl类。 这就是service+serviceImpl套路产生的背景。

---

---

这个是我到处找凑出来的，里面只标注了一个原著链接，告补