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

[lawsiki]

项目中存在挺多这种情况，mybatis querywrapper 无法满足，需要手写 SQL ，但没有其他逻辑，或者比较简单的一些数据转换逻辑，每个都封装一个 service 方法感觉很多余，但是直接穿层调 mapper 好像又不合理，大佬们是怎么处理这种情况的？

[luoyonghao]

还得是通过 service 调用。

[wander555]

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

[kerb15]

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

[xiaolongorigino]

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

[lawsiki]

@xiaolongorigino 都是查询统计的 SQL

[msaionyc]

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

[Rocketer]

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

[james2013]

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

[dayudayupao]

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

[huangzongzhuan]

评论区都非常理性~

[gam2046]

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

[chenPiMeiHaoChi]

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

[yule111222]

可以不写 service

[abcbuzhiming]

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

[ghost024]

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

[chenfcheng]

后面讲不准会拆 sql 吧

[zxcvbnm1992]

抓到一直菜狗

[zxcvbnm1992]

过来看我的代码怎么写的

[gejun123456]

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

[dssxzuxc]

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

[fkdog]

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

[qtxxm]

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

[layxy]

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