针对复杂 SQL 查询，是直接在 controller 层调用 mapper，还是要包装一层 service？

还得是通过 service 调用。

无所谓其实，消耗最大的还是 SQL 本生的执行

个人项目在 controller ，团队项目在 service

我认为还是通过 Service 调吧，但如果你真的确定这个 SQL 怎么都不会有多个 SQL 操作这种事务需求或者未来对其处理也不会做什么变更，直接调也没人会说你，小细节

@xiaolongorigino 都是查询统计的 SQL

放 service 层可以复用，可以很方便地做事务控制。如果确定没有其他场景用这个 sql ，放 controller 里也行，能过 cr 就行

我们 controller 只负责校验和转发接收到的数据，任何处理都在 service 层

放在 service
如果闲麻烦,可以用插件或者工具一键生成 controller,service,service 实现类,mapper,实体类等

抽一层的目的只是为了解耦和更好的抽象，不要被这个局限了，但是也不能不要，根据情况自己调整，有强制规范就按规范来，没强制规范自己能看懂能维护就行

评论区都非常理性~

啊这...好像只有我一个人和你们不一样，全都是调用的存储过程，代码里就没有 SQL 语句，后面的活都是给 DBA 干的了，我也不知道数据库到底长什么样子。

我有强迫症，controller 必须干净统一整齐，都拉在 service 里。

可以不写 service

@gam2046 应该是老项目吧，这种模式只在比较老的项目才这么干，或者你们的 sql 特别麻烦，新项目很少这么干的，DBA 首先很贵，其次存储过程难以调试

在 service 里面，第一是可以复用，并且一旦需要把查询出来的数据做一些逻辑处理的话可以直接在 service 的那个方法里面做，第二 controller 层按道理是不应该有任何业务逻辑的，这样能在 controller 层保持干净，如果项目规模不大你在 controller 层直接注入 mapper 看似没什么，但是一旦代码规模起来会变得很丑陋，你在 controller 的代码会变的越来越长，最后 service 层形同虚设，又要重构。

后面讲不准会拆 sql 吧

抓到一直菜狗

过来看我的代码怎么写的

都行，看你的项目，小项目快速开发直接 controller 调用，后期有需要再抽到 service 里面，大项目的话弄个 service 好点

把垃圾放一楼还是二楼的问题，不可复用的代码，放哪都行，可复用或者可能复用的，放 service 。代码一律放 service 的多半是常年这么写习惯了或者有强迫症，实际上放 controller 当然没问题。如果是我自己的项目，我用 mybatisplus ，不可复用的全写 controller 了，并且只使用 service ，mapper 都用不到，第一眼就能看到实际代码。如果是微服务并且几乎全是单表查询，mapper 层都可以删了。

复杂 sql 指的是？
除了大部分 db 内置函数、聚合统计，大多数涉及到多表 join 的都可以交给代码完成。

之前我都放入 service ， 最近开发一个小项目，为了方便就 controller 直接调用 Mapper 查数据了，针对列表页上的数据查询。当然，尺度把握不好就乱套了。小团队需要内部沟通好，规模复杂度上来了，可以考虑放到 service 层。
当然，新增修改删除之类的，还是放在 service 层的。

service 做业务逻辑处理,controller 不要放太复杂的逻辑,尽量保持 controller 简单