声明:原文出处http://blog.csdn.net/Earl_yuan/article/details/50382431,本人出于学习,收集干货,不作商业用途!
这是我看到的较为简单清晰描述mvc的各层关系的文章
view-controller-model
这是在学校就接触到的概念,在正式加入程序员队伍之前,我对其的理解也只仅仅停留在字面意思,即模型层+视图层+控制层。但是逐渐通过工作的磨砺,现在已经对其有了比较清楚的认识。
其实按照用户请求的执行顺序应该从左向右依次为view-controller-model。
- 视图层view:用于展示数据,与用户进行交互。
- 控制层controller:用于分发控制到来的请求,并调用模型层与数据库进行交互,以及将数据返回给视图层展示。
- 模型层model:数据模型,它与数据库进行交互,进行CURD操作。
如下图:
这里模拟一个用户查询和新增的请求。
当用户通过浏览器的web界面发起查询请求时,首先会被控制层controller分发,然后会调取相应的model层进行数据库查询。然后model层再将数据库查询到的数据返回给控制层,控制层再将其返回view层,view层web页面中进行显示。
view-controller-service-dao
以前,我一直认为可以直接在控制层就调用model层来进行数据库的交互。因为之前接触到的项目业务逻辑比较简单,所以直接在控制层就将很多工作都完成了。当我慢慢理解了MVC的分层架构后,我觉得这是不严谨的,耦合性太强了,违背了MVC的初衷,即解耦。所以随着MVC学习的深入,慢慢地又加入到了业务层service和数据访问层dao。那么上述的情景就可以有如下的表示:
- 视图层view:用于展示数据,与用户进行交互。
- 控制层controller:用于分发控制到来的请求,并将请求分发给相应的业务层。以及将数据返回给视图层展示。
- 业务层service:业务处理,调用数据访问层与数据库进行交互。
- 数据访问层dao:它与数据库进行交互,封装了对数据库的CURD操作。
当请求来了,controller就会将相应的请求分发到相应的service层,在service层中再调用dao层进行数据库交互。这里的dao层其实就是之前的model层,封装了对数据库的操作。这样一来,就把业务处理逻辑从controller中分离出来,从而实现了解耦。
通过网上的了解,在有些项目中,其实也是没有完全按照分层进行架构,省略了service层,直接将业务逻辑与数据访问揉在了一起,这样其实是不便于扩展的,为了项目的架构清晰,易于管理,方便扩展,还是应该按照分层的架构来构建项目。