目录
Pojo层（model层）：
- 实体层 数据库在项目中的类
- model是模型的意思，与entity、domain、pojo类似，是存放实体的类。
- 类中定义了多个类属性，并与数据库表的字段保持一致，一张表对应一个model类。
-
主要用于定义与数据库对象应的属性，提供get/set方法,tostring方法,有参无参构造函数。
- 其实就是实体类这一层，它是与数据库中的属性值基本保持一致的。
- 有的时候有些人开发写成pojo，有的写成model，也有domain，也有dto等，
- 实体类如果你不懂什么东西的话，那你就想成是它是范围。
Dao层（mapper）：
- 持久层，主要与数据库进行交互
- 又被成为mapper层，叫数据持久层，先设计接口，然后在配置文件中进行配置其实现的关联。
- dao层会调用pojo层，dao中会定义实际使用到的方法，比如增删改查。
- dao层的作用为访问数据库，向数据库发送sql语句，完成数据的增删改查任务。
- dao层的数据源和数据库连接的参数都是在配置文件中进行配置的，配置文件一般在同层的xml文件夹中
- 数据持久化操作就是指，把数据放到持久化的介质中，同时提供增删改查操作，比如数据通过hibernate插入到数据库中
- DAO层叫数据访问层，也叫mapper层 。
- 某个DAO一定是和数据库的某一张表一一对应的，
- 其中封装了CRUD（增加Create、检索Retrieve、更新Update和删除Delete）基本操作，DAO只做原子操作。
- 无论多么复杂的查询，Dao只是封装增删改查。
-
至于增删查改如何去实现一个功能，Dao是不管的。
Service层（定义接口）：
- 业务层，控制业务，Service层叫服务层，被称为服务，粗略的理解就是对一个或多个DAO进行的再次封装，封装成一个服务
- service层调用dao层接口，接收dao层返回的数据，完成项目的基本功能设计。
- 完成功能的设计和dao层一样都是先设计接口，再创建要实现的类，然后在配置文件中进行配置其实现的关联。
- service的impl是把mapper和service进行整合的文件 封装Service层的业务逻辑有利于业务逻辑的独立性和重复利用性。
- Service层叫业务层，被称为服务，粗略的理解就是对一个或多个DAO进行的再次封装，
- 封装成一个服务，所以这里也就不会是一个原子操作了，它需要事物控制。
- 管理具体的功能等！
- service包含了serviceImpl（service接口的实现类） 是提供给controller 使用的，
-
针对于某些业务将 Dao 的对于某些表的crud进行组合，也就是说间接的和数据库打交道。
controller层（处理前台发送的请求）：
- 控制层 控制业务逻辑
- controller层负责具体的业务模块流程的控制，controller层负责前后端交互，接受前端请求，调用service层，接收service层返回的数据，最后返回具体的页面和数据到客户端。
- Controler负责请求转发，接受页面过来的参数，传给Service处理，接到返回值，再传给页面。
- 管理业务（Service）调度和管理跳转的。
util层（工具类）：
- 工具类，它是用来封装相应的方法，然后将其放在对应的util包下，使用的时候直接调用就可以了。
- 比如，日期转换util，http请求等相关的工具类。获取properties文件属性等等都可能会被放进util
VO层（方便前端获取数据）：
- vo层的存在就是方便前端获取数据，后端将前端的需要的数据做一个整合，打包成一个类。
Filter层（对用户请求的预处理）：
- Filter对用户请求进行预处理，接着将请求交给Servlet进行处理并生成响应，最后Filter再对服务器响应进行后处理。
业务逻辑：
controller - - > service接口 - - > serviceImpl - - >dao接口 - - > mapper.xml - - > db
在具体的项目当中，其实它的流程为：
- 首先Controller层调用了Service层的方法，
- 然后Service层调用Dao层中的方法，其中调用的参数是使用Pojo层进行传递的。
- 总的来说这样每层做什么的分类只是为了让业务逻辑更加清晰明了，写起代码更加方便高效，
- 所以有时候也需要根据具体情况来作为依据，
- 但是大体的都是这样处理的，因为它其实就是提供一种规则，让你把相同类型的代码放在一起，这样就形成了一个层次，
-
从而达到分层解耦、复用、便于测试和维护的目的。