大家好啊，我是司空，最近在工作空闲之余正在学springBoot，学到了对于mybatis的配置，外面波及到几个不同层之间的应用让我有点摸不着头脑，没法，公司用的还是十年前的老框架，对于当初这些框架真没啥理解，不过MVC机制是没有变了，我也就联合我所学的内容和工作中的理论教训，谈一谈我对这几个层之间的理解吧。
根本理解
上图用的是我整顿思路的时的草图，不具备专业性，大家别当真了哈，看看思路就好dao层：用于定义操作数据库的接口办法，须要怎么调数据库就定义什么办法在这
mapper层：用于间接对数据库进行操作，sql语句就写这
service层：用于定义业务实现的接口办法，须要实现什么业务就定义什么办法在这
serviceImpl层：用于实现业务接口，能够操作治理dao层获取想要的数据
其余几个层：如controller,view,model,entity就简略过一过，别离负责数据的解决，展现，存储和封装。就不具体说了，我新学的次要是下面四个。
一些思考
依据上图咱们晓得，其实对于实现一个性能来说，只须要model,view,controller层就行了，那为啥还要在model到controller之间插入dao层和service层呢？ 让咱们带着这个问题，去看一下应用ssm框架实现一个view渲染的事实门路映射吧。
上图用的是我整顿思路的时的草图，不具备专业性，大家别当真了哈，看看大体门路就好能够看到啊，view层和controller层，controller层和service层，serivce层和dao层，都是多对多的关系。而service层和serviceImpl层，dao层和mapper层，mapper层和model层则是一对一的关系。
问题就出在这对应关系上！
试想一下，这只是一个view，就可能调用多个controller去获取数据，那两个view呢，一堆view呢。如果绕开service层和dao层以及mapper层，间接让controller层与model层进行交互，那很显著会呈现一个问题，代码的大量反复以及耦合性强。如view1须要model1的userId,view2也须要，假使绕开三层间接让controller层与model层进行交互，那么view1须要与model1建设一次连贯，取一次userId。view2也须要与model1建设一次连贯取一次userId,这是很蠢的行为。
一个办法，如果须要写三次以上，就应该封装起来，更别提调数据库这种如此频繁的行为。再说，如果数据库表受到更改，难道你去每个controller外面改一次sql语句吗？
这就引出了咱们第一个问题的答案：为啥还要在model到controller之间插入dao层和service层？ 目标就是为理解耦，进步代码的开发效率。这也就是方才咱们提到的多对多关系的由来。
仔细的敌人可能发现了，方才我不仅说到了多对多的关系，还存在着一对一的关系。那么这个一对一的关系又是为了什么呢？
实际上，如果咱们把service层与dao层合起来，在面对一些小型业务量的场景时，是齐全没有问题的。起初我也搞不懂，为啥要用service的接口办法调用另外一个接口的办法去实现。可当业务量下来后，才发现这是一个如许理智的抉择。
我认为建设service层和dao层最间接的益处就是繁多职责化，这也是SOLID准则中的繁多职责准则（Single Responsiblity Principle），十分经典的体现，service只用思考业务如何实现，不思考数据如何获取。dao层和mapper只用思考数据如何获取，不必思考数据要被拿去干什么。在多人合作开发与业务高复杂度场景中这种思维非常好用。
一些疑难：
看见网上一些博客，都说dao层个别是对应着某个表。我集体并不认同，一是表太多创立太多接口类难以治理。二是如果遇到那些多表联查的场景时，该把这些接口办法放到哪个类外面呢？
我认为较好的就是将dao层接口类与库绝对应，一个库对应一个dao层接口类，而后把一些比拟重要的表或者几张表独自建设dao层接口类，如用户信息，平安登录表等等。能够在方便管理的状况下又正当地爱护某些重要数据。所有有人晓得为什么dao层接口类要与表绝对应嘛？有的话请在评论区通知我哦。
以上就是我对这几个层的一些肤浅了解，如果有谬误请大家多多斧正，咱们独特学习，共同进步。peace&love❥(^_-)