controller和service的对应关系 30
实体类和表一一对应，dao和实体类一一对应。
现在有个首页下面要显示文章、新闻、娱乐、交流4个模块，建5个controller分别对应 (A、B、C、D、E)
controller是要对应一个service，然后service调用多个dao类，
还是controller调用多个service类，然后service和dao一一对应。
如果service和dao一一对应，那会造成service过多。
如果controller调用多个service，那会造成service里面调用dao的代码重复。
比方我首页controller调用首页service，service调用4个dao。
然后文章controller调用文章service，service又要调用上面的某一个/某几个dao，造成代码重复。
请问哪种比较合理？
各位实际开发中怎么处理这样的问题的？ 展开
Service层：
Service层主要负责业务模块的逻辑应用设计。同样是首先设计接口，再设计其实现的类，接着再Spring的配置文件中配置其实现的关联。
这样我们就可以在应用中调用Service接口来进行业务处理。Service层的业务实现，具体要调用到已定义的DAO层的接口。
封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性，程序显得非常简洁。
Controller层:
Controller层负责具体的业务模块流程的控制，在此层里面要调用Serice层的接口来控制业务流程，控制的配置也同样是在Spring的配置文件里面进行。
针对具体的业务流程，会有不同的控制器，我们具体的设计过程中可以将流程进行抽象归纳，设计出可以重复利用的子单元流程模块，这样不仅使程序结构变得清晰，也大大减少了代码量。
释义：
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层存在的意义了。
扩展资料
Service逻辑层设计：
Service层是建立在DAO层之上的，建立了DAO层后才可以建立Service层，而Service层又是在Controller层之下的。
因而Service层应该既调用DAO层的接口，又要提供接口给Controller层的类来进行调用，它刚好处于一个中间层的位置。每个模型都有一个Service接口，每个接口分别封装各自的业务处理方法。
在DAO层定义的一些方法，在Service层并没有使用，那为什么还要在DAO层进行定义呢？这是由我们定义的需求逻辑所决定的。
DAO层的操作 经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。
按理说，业务逻辑是在service中写的。controller只是起到了一个请求转发的功能。
但实际开发中，还是看程序员自己的逻辑。
通常开发中，我们都是建议，dao只做原子操作，增删改查。
业务逻辑放在service，这里就可能用到多个dao，如何需要事物控制，这里还需配置事物。
controller负责请求转发，接受页面过来的参数，传给service处理，接到返回值，再传给页面。
有一点说明一下，service会调用其他模块的dao其实是正常的，不算代码重复。
我要问的是一般开发情况下哪种情况比较常见：
一个controller对应一个service，还是对应多个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层存在的意义了。
