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

要么你代码检查自动拦截，要么你人工 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 调用才垃圾，没有二十年脑血栓写不出这样的代码

那咋了

能跑就行，之前有 Entity 的 get 方法里面调 dubbo

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;