如果你的组员，用 controller 直接调用 mapper，是不是可以直接 fire 了

就问你能不能用？

不让中间商（ service 、manager 层）赚差价

嘿，有的接口没啥逻辑，我就直接调 mapper

用 cursor 写有的时候会出现这种情况

@sumarker 把 mapping 写在 mapper 里，不让 controller 赚差价～

没给你直接调用数据库就已经算不错了（来自对有些实习生的怨念）

听起来很离谱, 但仔细想没啥问题, op 可能纠结的是数据隔离?

？我现在接手的代码，逻辑啥的都在 controller 里面，不是新加的功能我都懒得创建 service...

大部分情况下，你的组员不归你控制。。哈哈

fire 不 fire 得看项目是否长远， 项目结构是否妥善划分，以及团队约定

如果是仅查询的孤立逻辑 controller 直接调 mapper 其实我觉得挺正常的

这个不至于吧，代码逻辑少，懒得创建 service

不但调，mapper 还返回 list<map<string,object>>

@xiangyuecn 入参也是 map<string,object>

@xiangyuecn #12 +1 我经常这么干，有些没写过 service 的操作直接调用 mapper ，等后面再有相同的操作再重构不就得了，大家都是草台班子，较真干嘛

那种过 service 透一层但没有额外逻辑的行为,就教条主义而已

逻辑不复用的话有什么要紧？如果 controller 的作用仅仅是调用 service 的话，那么要 controller 还有什么作用？

这不是他的黑历史,是他来时的路

桌面单体应用可以，web 应用只允许项目启动的系统配置这样子搞，其他情况一律打回去重写，或者立马开除

这种想法等同于“不喝就是看不起我”

你是皇帝么，动不动就砍头砍头的。。

无规矩不成方圆，你这样做，他那样做，不就是个乱字可以形容，后续的麻烦不知道有多少； 不管是对个人而言，还是对公司而言，要有规矩才成方圆，才走的远。

我们公司连 controller 和 mapper 都没有，接口通过自有框架直接在 service 上声明，数据库通过框架包了一层的 jooq/mongoclient 等调用，完全没有 mapper/repository 的参与

我现在就是直接在 controller 里面写各种代码。
MVC 时代 controller 是用来控制渲染的，现在都是 restful 接口，根本不需要什么渲染，很多 controller 的方法就一行代码调服务，脱了裤子放屁。
很多 javaer 就是相当教条主义，也难怪别人黑

见识到 java 的恐怖了

是

分读写类型吧。

只读的 Controller-Action ，怎么方便怎么来，直接原生 SQL 都无所谓、一般都是 SQL DSL 。

但要是牵扯写的操作，还是通过 Service 、领域（业务）对象来处理比较好。

为什么一些规范要求变成了 javaer 的吐槽点呢。难道其他语言没有类似的？比如 python 的__xx__？

我只能说以我的经验来看，让代码变成屎山的不是规矩，而是需求和开发者本身以及他们的迭代。

又不是不能用，刚开始写代码我也是需要各种分类，各种抽象，其实对大部分业务只是脱裤子放屁。一个 controller 一把梭，业务在一个地方的代码从上到下走完简单清晰

@irrigate2554 要定好规则，弄好后从没出现过

1.工资决定写在哪里
2.公司代码与我无关
3.方便后续优化

@woniu7 开发者没有觉悟，没有意识，现实中有很多。无奈。

个人可以这么搞，公司项目尽量不要。
当然，能跑就行。doge

你就说能不能跑吧

话不要太绝对，有些 hello world 级别的组件，有人也硬要套得里三层外三层的，老板把他 fire 了，我重写总共不到 200 行

要看公司有没有规范，没有这方面规范，那人家怎么写是他的自由。不过相对而言 java 项目真的比较喜欢分层，不管是公司级别的还是开源项目，面向对象都玩出花儿来了，spring 和 tomcat 代码真的看得想吐。像 redis 或者 etcd 这种代码都是一个文件写完一整块儿的逻辑，看起来真的丝滑～

javaer 都这么吓人的吗

我一开始也是一层包一层，后来发现其他人都是 controller 一把梭，我吭哧吭哧搞半天还不如加入，反正都是草台，我自己一个人做的项目才分一分层。

你的组员，用 controller 直接调用 mapper
是你的问题，而不是他的问题。

我有同事就这样写，我也没办法

以前 controller iservice serviceimpl mapper
现在 controller service mapper

不会
我之前看 spring boot 官方的视频教程就是 controller 直接调用 repository

不管有没有多个实现，service 层必须要写 interface ，不写的话开除。
不管业务是否复杂，maven modules 必须上，拆分成数十个模块，不会搞的开除。
不管多大的项目，SpringCloud 、注册中心、配置管理、redis 集群、消息队列必须安排，不安排的话开除。
别问我并发有多高，我要一台 64 核，256G 内存的机器，没有的话开除甲方。

这多大规模的项目啊，要这么严格

如果我的 leader 根据单独某个技术做法（就算确实很糟）就让我 fire 一个人，我会把这个 leader 换了

引用下 《投名状》
好奇
你们几个人儿？

我们简单逻辑，直接在 controller 中用 orm 来调用数据库。。。

@nealHuang 嗯，我说没提需求默认配置的情况下偶尔出现

这不只是一个 controller 调用 mapper 的问题
首先你们有没有制定好规范?

所有的乱写一是因为人, 二是因为规范

如果没有规范,而且允许人乱写,每个人都有各自的写法 项目混乱很快

很多项目基本只有一个 Service 实现, 还是要搞个 interface 真是恶心

还有另一外一种过分“守规矩”的，明明自己的 service 抽象的一点都不通用，永远都不会有多个实现，非得一对一的都搞成 interface+impl

@COOOOOOde 撞回复了

又不是不能用

写 java 写的目光呆滞思维僵化

@sean250031 #52 不打算给单元测试留个口子了？

没什么业务逻辑的，这么写也没什么问题，毕竟这东西也不会产生什么 bug ，可以跟组员提建议和要求，但不要过于注重此类问题，甚至阴阳苛责，毕竟制定团队技术规范目标是协同开发，尽量避免 bug 产生，不要舍本逐末，过于注重代码洁癖，应该多注重逻辑思维能力，毕竟逻辑思维能力决定了业务 bug 的下限。

@sean250031 #52 合理,非得自己再套一层裹脚布,又臭又长。

如果只是单纯的数据库操作，没啥问题，如果是组合的数据库操作，还有可能复用的话，我会写到 service 里，这没啥的

人多维护就按照大家的习惯来，自己维护的项目就按照优雅的方式来

动不动上升到 javaer 怎么怎么样也挺无聊的..

java 仔最近写 python ，感觉那叫一个自由

要么你代码检查自动拦截，要么你人工 review 拒绝合并。
公司有没有规范？公司接不接受你的执行成本？落实力度怎么样？

有什么问题？

你的问题更大点！你的组员菜归菜，要是你劝导过，屡教不改，那 fire 没问题。人家菜，你不想着拉一把，想着丢人家饭碗。真恶毒啊。都是牛马，谁也别看不起谁，今天你嫌他菜，明天在大佬眼里你何尝不是一只菜鸡。

没必要这样。主打微服务。监控只要每个接口响应速度达标就可以呢。你爱咋玩都行.有 docker 玩新的技术都行。
规规矩矩的。实际上一套老框架。不进则退。上个班还没自己练手新框架。新脚手架。公司都倒闭了
你觉得部门要长远。但是压抑成员的学习能力也不好。上班哪家公司能撑个 5 年 10 年的
成员只要用自己最擅长。最高效完成任务就好。但是现实中还是很多老大各种条条框框的。拿着 N 年前的技术在玩。手动更新服务器代码都大有人在

没什么可不可以的, 规范和最佳实践很多都是在前提背景下产生的. 你觉得不可以只要你有领导权你制定规则就好了.

很多简单的业务怎么写没啥问题，但是有 AI 了，可以一开始就分开写。 又不会麻烦。 写进 Promt 里就好

可能无关的回复.javaer 里有没有可能男比较多,挺容易被规训成

@zhouxiaoxiao 我现在接手的项目都是这么写的 而且是拼音首字母命名 世界真是草台班子 已经想跑路了。。

哈人,我写 C#不写 controller,class 添加一个固定接口,项目启动扫描接口自动生成路由,代码都在里面一把梭

serviceimpl 是为了写业务实现的，如果没什么业务，只是一个单独的查询，我觉得直接调 mapper 没问题，如果硬说 以后会增加业务，我无话可说

取决于项目本身的规范程度。

就我司而言，是实行 CQRS 规范的
仅查询数据，没有副作用的，走 Rpc Service -> Query -> DB 这个路径，有时甚至不用 ORM 直接写 sql
除此以外，需要写入/更新数据，或者有副作用的，走 Rpc Service -> Command -> Domain Service -> Repo, 并且每一层之间必须定义接口

过度封装就是强行给自己喂屎，完全没必要，代码是为了易读、健壮，不是为了践行茴香豆必须怎么吃

controller 里一行 serice 调用才垃圾，没有二十年脑血栓写不出这样的代码

那咋了

controller 调 service, 很大程度是为了可以弹性扩展 service 吧.

@asmoker 要是 map<string,object>我都谢天谢地了，我接手代码定义一个变量是这样的：
Quartet<org.javatuples.Pair<Map<String,List<Pair<Query, Update>>>, Map<String,List<Pair<Query, Update>>>>, org.javatuples.Pair<Set<XXXDTO>, Set<XXXDTO>>, List<XXXEntity<DDDEntity>>,XXXValidate> quartet = null;

谢谢，本来就烦 java ，现在更烦了

if 你有权 fire and 想 fire：
fire 呗
else：
搁这儿问了也没用

魔怔

符合我对 javaboy 的刻板印象，你平时是不是还非常推崇 java 阿里编码规范

无所谓了， 我甚至 service 接口都不写， 直接 serviceimpl 写实现

controller 直接调用 jdbctemplate ，返回 list<map>，好像也没啥大问题，直接省了创建 service ，mapper

满屏的 controller 里写一句调用同名 service ，
满屏的 service 接口只有一个 impl ，以及 impl 里满屏的 @autowire
满屏的同名 get ，set @lombok
龟龟范范，却控制不到业务逻辑代码本身
仔细一看，结果发现一群无聊的花架子加上混乱不堪的核心逻辑罢了

组员把 sql 写在 jsp 中 阁下如何应对

@zhouxiaoxiao #21 差不多得了，一般情况都是公司先比代码走。

我还遇到过同时 controller 调 controller 的，劝说无效还被白眼，祝他安好

在逻辑不复杂和没复用的情况下，为啥一定要写 service 。实在搞不懂。

还得是我们 Next.js ，直接在 UI 代码里写 sql

这既不是水平问题，也不是不服管理屡教不改态度问题，谈何 fire

@Narcissu5 他们现在就是为了分类而分类

java 刚开始封 everything is object 为圭臬，直到函数流式大行其道。
能跑就行，要求不要太多。

@Narcissu5 是的，我就是直接 controller 写实现，我以前也是 javaer 还有搞 service 和 serviceImpl ，然后 controller 就写一行代码，真 tm 烦

好搞笑！

@chocotan 因为代码的清晰度和你分几层没关系，分层唯一的作用是复用。如果不存在复用，那就是一种累赘。国内太多人学歪了

可能这就是 java 味吧

病得不轻，你既然强调规矩，先问问你提前讲过所谓的规矩吗？其次 CQRS 情况下这么干很正常的。