初步了解SSM框架中的Dao层、Mapper层、Service等层层与层之间的使用让我有点摸不着头脑，没办法，公司还在用十年前的老框架，真不知道现在对这些框架了解的比较多，但是MVC的机制并没有变，所以我就结合我所学的来说说我对这些层的理解。基本明白上图是我整理思路时画的草图。这不是专业的，所以不要当真。看看这个想法。Dao层：用于定义操作数据库的接口方法。方法在这个mapper层：用来直接操作数据库，sql语句写在这个service层：用来定义业务实现的接口方法，定义需要实现什么方法在这个serviceImpl层：用于实现业务接口。可以操作管理层dao层获取想要的数据。其他层：如controller、view、model、entity只是简单的传递过去，分别负责数据的处理、展示、存储和包装。我就不细说了，主要学到的就是上面这四个。一些思考根据上图，我们知道其实实现一个功能只需要model、view、controller层，那为什么还要在model和对象之间插入dao层和service层呢？控制器？下面我们就带着这个问题，来看看使用ssm框架进行视图渲染的真实路径映射。上图是我整理思路时画的草图。这不是专业的，所以不要当真。看一下大概的路径就可以了。视图层和控制器层，控制器层和服务层，服务层和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层和dao层最直接的好处就是单一职责，这也是SOLID原则中的单一职责原则（SingleResponsiblityPrinciple）。这是一个非常经典的体现。服务只需要考虑业务如何实现，而不需要考虑数据如何获取。.dao层和mapper只需要考虑如何获取数据，而不需要考虑如何处理数据。这种思路在多人协作开发和高复杂度的业务场景中非常有用。一些问题：在网上看到一些博客，说dao层一般对应某个表。我个人不同意。一是太多的表创建了太多的接口类，难以管理。第二，遇到那些多表联合查询的场景，应该把这些接口方法放在哪个类中呢？我觉得还是把dao层接口类和library对应起来比较好，一个library对应一个dao层接口类，然后再创建一些重要的表或者表单独创建dao层接口类，比如用户信息，安全登录表格等。一些重要的数据在方便管理的同时得到了合理的保护。有谁知道为什么dao层接口类要对应表？如果是这样，请在评论部分告诉我。以上是我对这几层的粗浅理解。如有错误，请指正。我们将共同学习，共同进步。和平与爱?(^_-)
