controller和service层的一些见解

接触java EE开发一年不到，刚开始接触时用就用到spring MVC，因为当时公司业务比较简单，所以service层和dao层实际上是一样的，业务逻辑全部放在了controller层来做；当时觉得很纳闷，service层感觉是多余的，根本用不到； 

最近接触的项目，架构师设计的框架，直接根据模型设计dao层接口和service接口，代码写了不少，突然发现这么定义接口很多功能是没法实现的。于是回头重新思考了spring MVC模型，刚才看了篇非常不错的博客，感觉作者能把这个问题解释清楚了。 

还是从MVC三层模型开始，这三层模型的设计之初，就是为了将业务层（controller）、视图层（view）以及模型层（modal）区分开来。需要注意的是，这里并没有数据库这个概念，所以模型层会有一些冗杂，两个表的联合查询出来的数据，会被封装成一个模型交给控制层；同样的，控制层因为没有服务的概念，如果项目比较大，也会变的有些冗余。 

基于controller和modal层并没有很好的实现模块化，因此，我们将modal层去掉，改为更加原子化的dao层；同时，将controller层的业务逻辑，划分成多个服务。每个服务可以组合使用dao层数据，组装成一个服务，比如用户的注册服务；而controller层，调用多个service服务完成url请求。 


简单来说，增加service层，替换modal层，第一是细化了数据模型，使得我们在改动某张表时，只需要改动dao层实现即可，最大化的减少了代码的改动成本；当然，更多的情况是service服务和controller可能都需要更改； service层将controller的逻辑分类，保证了controller的逻辑更加清晰。 

举个生活中的例子，用户预约某个酒店的客房，这是酒店首先会调用验证服务对用户提供的信息进行验证，之后调用预约服务进行预约，如果预约失败，酒店可能会把客户的预约信息提交给另外一家酒店请求它们的预约服务，然后将结果返回给客户； 

对于服务层来说，需要判断酒店是否有空余客房，之后修改客房信息，同时将客房和用户信息存入临时表。这里至少需要两种不同的dao层服务实现service。 

所以整体上来看，controllrt->service->dao至少是一对一，更多的情况下是一对多。这也就是service层存在的意义了。