SpringBoot 三层架构 Controller、Service、Dao作用和关系详解

首先创建一个springboot项目。

model层

model层也叫pojo层或者entity层，个人比较喜欢pojo层。

一般数据库的一张表对应一个pojo层，并且表中所有字段都在pojo层都一一对应。

然后要先建一个pojo的package，代表它是实体层。

再在该package下创建一个Goods的java文件，创建的对象都是和表里字段一一对应，如下所示：

package pojo;

import lombok.*;

@Data

public class Goods {

    /*

    商品编号

     */

    private String GNo;

    /*

    商品名称

     */

    private String GName;

    /*

    商品价格

     */

    private Double GPrice;

}

这里的lombok的作用时为了简化代码，因为对于private这样的对象，想要调用它的时候，需要get和set两个方法，而有了lombok之后就可以不用写，直接用即可。

不过要添加依赖和注解@Data，lombok还有很多其他用法，之后可能会出一篇博客。

通过maven下载依赖：

<dependency>

	<groupId>org.projectlombok</groupId>

	<artifactId>lombok</artifactId>

	<optional>true</optional>

</dependency>

这样数据库里的字段，我们就可以用对象来表示。

但是model不属于springboot的三层框架。

主要说明是dao层、service层和controller层。

这些已经是属于后端了。

对于一个项目，安全性是非常有必要的，所以springboot很好地体现了这一点。

比如：

想要访问数据库并且操作，只能通过dao层向数据库发送sql语句，将这些结果通过接口传给service层。

想要处理数据，要先向dao层请求数据，对dao层传过来的数据进行加工处理，将这些处理好的数据通过接口传给controller层。

客户想要查询或修改数据时，要先向service层请求数据，收集service层传过来的数据，将这些数据通过接口显示给客户，一般通过html等方法给客户。

下面会一一说明。

Controller：

顾名思义，业务控制，就是控制业务层Service的，它的作用主要是架起了外界与业务层沟通的桥梁，移动端，前端在调用接口访问相关业务时，都会通过Controller，由Controller去调相关的业务层代码并把数据返回给移动端和前端；

Service：

业务层，所有的内部的业务逻辑都会放在这里处理，比如用户的增删改查，或者发送个验证码或邮件，或者做一个抽奖活动等等等等，都会在Service中进行，当然，业务离肯定是离不开数据的支持，因此Dao层是必不可少的；

dao层

dao就不做解释了，数据持久化层，就是和数据库打交道的，而实现持久化层的框架又有很多，而常用的有两种：JPA和MyBatis，JPA是SpringBoot官方的，前身就是著名的三大框架之一的Hibernate，好处是不用手写SQL（当然它也支持手写，如果必要的话），国外用的比较多，而MyBatis则在国内比较流行，原因是它的灵活性非常高，但是需要手写SQL语句！关于它们谁更好的争论从来没有停止过，这里不作讨论，不过可以给出自己的一些建议：

项目复杂程度一般，追求稳定，迭代速率低的可以用JPA；

项目较复杂，需求变更频繁，迭代速度快的可以用MyBatis；

我们了解了他们的作用后，可能有同学会问：为什么必须要写Service层，我直接用Controller层操作Dao层，省去Service层，岂不是更简单？

我们知道Controller的作用，它是一个桥梁，或者说一个中间者/服务者，打个比方，一个底层销售想见马云，但马云岂是谁都可以见的？如见了面安全如何保障？所以就会通过一个中间者或服务人员与销售沟通，销售通过中间者传达自己的目的，中间者再经过整理后请示马云爸爸，最后把马云爸爸的反馈信息转给这个销售，这样销售即达到了自己的目的，马云爸爸的安全也得到了保障，两全其美！

因此，Controller层是不允许直接操作数据库的！另外，Service对以后的分布式部署有极大的作用，它就像一个服务员，哪桌客人需要点菜了，就喊一声服务员！对应的，外界需要完成什么样的业务，就通过Controller去调用不同的Service，需要记住的是，Controller只是一个中间者或者转发者，不应该在Controller里暴露Service的业务逻辑，而应该直接转发Service的业务处理结果！

一般的，一个Controller对应一个Service，一个Service对应一个Dao，一个Dao对应一个数据库表，当然根据项目或业务复杂程度，一个Controller可以调用多个Service，而一个Service也可以调用多个Dao，但是Controller层不允许互调，Service层也不允许互调，意思就是AController不能直接调用BController，AService也不能直接去调用BService，遵循高内聚低耦合原则！

这样，客户可以通过请求的方式，将数据从前端传给Controller层，然后一层一层传下去，在一层一层地传上来，实现了后端开发。

是不是发现和前端没什么关系？

是的，springboot还有一个优点就是实现了前后端分离，从而工作人员分配任务的时候更加具有条理性。而三层的架构可以让程序员很快地知道bug出现在哪里，哪一层，哪一文件，很快的修改bug。

呜呼，总而言之，springboot作为web开发的一个主流框架，正式因为这些优秀点让它脱颖而出。