工作一年了，在工作中也完成了几个项目，但是都是由公司的架构师搭建好了整个项目的框架，我们在其中进行业务逻辑的开发。还没有真正完整的搭建过一个web项目，所以最近自己就动手搭建一个springmvc+struts2+mybatis的练手项目时，在这过程中更加深入的接触到了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层，直接将业务逻辑与数据访问揉在了一起，这样其实是不便于扩展的，为了项目的架构清晰，易于管理，方便扩展，还是应该按照分层的架构来构建项目。