即使放到service 也还是会一坨。。还是需要其他的方法来规避 业务复杂的情况，代码可维护性差

标准的MVC确实是直接在controller中实现业务逻辑，但实际项目里，还是会建议在controller和数据库操作之间封装服务层。
一方面，controller在对应不同的请求url，从功能上会存在很多重复；不好维护；
另一方面，要考虑你的服务功能将来可能暴露给其他前端，比如其他应用接入，或者不同的终端（如APP、移动H5等）；有些服务甚至可能单独剥离出来独立部署；

很不好，扩展起来很费劲，维护性也很差。

controller应该是薄薄的一层，业务逻辑尽量后置在服务层去处理，在服务粒度、服务利用上也更加自由。

今天让同事看代码.同事第一句话就是,你应该把controller这段代码放在service中;=_=;
主要看业务复杂度吧,如果很简单的一句业务那没有从controller到service,再到dao;也要看整个团队的开发规范是如何;

当然不好啦，controller层只负责业务数据交互，业务逻辑都交给service层处理

一般controller层=》Service层=》Dao层。
1.controller层，接受请求，进行分页，DTO对象封装操作。
2.service层，执行逻辑，控制并发，事务。
3.Dao层，与数据库交互。

现在我接手的项目Controller层也是奇大无比，一个方法上百行，里面有多层if嵌套，感觉这样最大的问题就是在后期维护时会很麻烦，需要理解之前的业务逻辑才能更改；个人感觉较好的方法是controller-service-dao，由service负责具体的逻辑操作，3者之间依次调用，彼此之间尽可能解耦；代码要尽可能可扩展。