文章目录
前言
提示：这里可以添加本文要记录的大概内容：
我在上一篇文中说过代码编写流程
1、画页面，编写 A.jsp
2、编写客户请求地址，发起客户请求，编写 B.jsp
3、编写控制层代码 (xxxController.java)
4、编写业务层代码（xxxService.java)
5、编写数据持久层代码（xxxDao.java 和 xxxDao.xml)
————————————————————————————————————————
今天再来说一下他们之间的关系
提示：以下是本篇文章正文内容，下面案例可供参考
一、model
model层也就是数据库实体层，也被称为entity层，pojo层
一般数据库一张表对应一个实体类，类属性同表字段 一 一对应。
实体层中一般会自动生成Getter、Setter、to String方法和构造方法
Eclipse中快速添加Getter、Setter方法
Eclipse中快速添加to String方法
Eclipse中快速添加构造方法
idea中快速添加Getter、Setter方法
此处借用网上经典动图展示：
idea中快速添加to String方法
idea中快速添加构造方法
此处借用网上经典动图展示：
二、Controller 业务控制层
controller层的功能为请求和响应控制。
controller层是不允许直接操作数据库的！controller层负责前后端交互，他是个桥梁，架起了外界与业务层的沟通，接受前端请求，调用Serice层的接口来控制业务流程，接收service层返回的数据，最后返回具体的页面和数据到客户端。
就像是一个公司一线工作人员要见公司老板反馈信息，所以这个一线人员就会通过经理与老板传达自己的目的，经理再经过整理后请示老板，最后把老板的反馈信息转给这个一线工作人员。
另外，Service对以后的分布式部署有极大的作用，它就像一个服务员，哪桌客人需要点菜了，就喊一声服务员！对应的，外界需要完成什么样的业务，就通过Controller去调用不同的Service，需要记住的是，Controller只是一个中间者或者转发者，不应该在Controller里暴露Service的业务逻辑，而应该直接转发Service的业务处理结果！
三、Service 业务层/服务层；
所有的内部的业务逻辑都会放在这里处理，
比如用户的增删改查，或者发送个验证码或邮件，或者做一个抽奖活动等等，都会在service中进行
service层是建立在dao层之上的，建立了dao层后才可以建立Service层，而service层又是在controller层之下的，service层既调用dao层的接口，接收dao层返回的数据，完成项目的基本功能设计，又要提供接口给controller层的类来进行调用，它刚好处于一个中间层的位置。
因此Dao层是必不可少的；
每个模型都有一个service接口，每个接口分别封装各自的业务处理方法。
四、Dao 数据库持久化层；
dao层也被称为mapper层。
dao层就是和数据库打交道的，负责与数据库进行联络的一些任务都封装在此，dao层向数据库发送 SQL语句，完成数据的增删改查任务。
dao层的设计首先是设计dao的接口，然后在Spring的配置文件中定义此接口的实现类，然后就可在模块中调用此接口来进行数据业务的处理，而不用关心此接口的具体实现类是哪个类，显得结构非常清晰，DAO层的数据源配置，以及有关数据库连接的参数都在Spring的配置文件中进行配置。
DAO设计的总体规划需要和设计的表，和实现类之间 一 一对应。
DAO层所定义的接口里的方法都大同小异，这是由我们在DAO层对数据库访问的操作来决定的，对数据库的操作，我们基本要用到的就是新增，删除，更新，查询等方法。
因而DAO层里面基本上都应该要涵盖这些方法对应的操作。除此之外，可以定义一些自定义的特殊的对数据库访问的方法。
总结
DBUtil.java
一般的，一个Controller对应一个Service，一个Service对应一个Dao，一个Dao对应一个数据库表，
当然根据项目或业务复杂程度，一个Controller可以调用多个Service，而一个Service也可以调用多个Dao，但是Controller层不允许互调，Service层也不允许互调，
就是AController不能直接调用BController
AService也不能直接去调用BService，遵循高内聚低耦合原则
本篇文章部分内容借鉴了其他博主的文章，但我忘了哪篇文章了，在此十分感谢那篇原创文章的博主