共计 1819 个字符，预计需要花费 5 分钟才能阅读完成。
大家好啊，我是司空，最近在工作空闲之余正在学 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❥(^_-)