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

@IamUNICODE 这和教条是两个极端，一整个项目怎么可能没有复用的代码和解藕的地方。不是分层不行，我觉得还得看情况。写 java 和 spring 的都是什么天才，复用搞出去做一份不是本能吗，有相同的行为做接口不是写代码本能吗。不会是套了半天 service ，impl ，mapper ，get set 不知道是为什么吧，只是规矩让他们这么干所以这么干，不会吧不会吧

我觉得问题不大，关键看你们使用的是什么模式。如果是简单需求使用事务脚本模式的话，在 controller 里直接调用 dao 没有什么问题的。

这个，代码只要逻辑清晰，结构优美，读起来没问题就好，别搞这些花花肠子，有什么意义。难不成吃饭前忘了洗手就犯了天条

多年以前研究过这个问题，看到过一篇文章（时间太久找不到出处了），其中有一段 spring 官方人员对 controller 、service 、dao 分层的说明，这种分层模式是官方演示 spring 框架搭建项目时的示范，而不是一个要遵守的范式。其中 service 层作用只是“事物脚本”罢了。
———— 以上内容来自于曾经阅读过的文章的记忆，以下内容是个人主观评价————
如果强行分层，也不是不行。简单的查询业务，去除 service 层，也无伤大雅。
因为这点小事要 fire 人家，duck 不必！大家出来工作都是为了混口饭吃，劝你做个好人！

模式（或者架构）需要匹配业务本身的复杂度，如果简单的业务用例也要使用接口层-应用层-领域层-基础设施层（可能还有装配层和事务层）的架构，开发效率会很差。

@FreeEx 我之前就疑问为啥 interface 只有一个实现的时候 要外面放一个 iterface

我之前在组内推广某个分层设计，我觉得很好的。都遭到拒绝了，很多人愿意一把梭。不愿意搞那么“绕”。
在他们眼里，什么鸡吧分层，什么鸡吧抽象，不如我一把梭来的快。

不过话说回来：

你平时怎么写？你是怎么分层设计的？
别光碰，你讲一下，让我看看你的水平。

@FreeEx 最后一句倒反天罡

Java 团队需要大清洗一下，

基于以上的回复，我觉得我们都有个共识：php 天下第一 doge

1. 组内有明确的开发规范文档吗？或者说有在组会强调过开发规范吗？
2. 组内 Git 有代码质量检查的流水线任务吗？有代码 Review 机制吗？
3. 合并 master 权限在你手里还是在他自己手里？

123 都做了 打回去让重写，你自己受不了他听不进去就开了。但是上面都没有，那就是你自己有病🙄

@COOOOOOde #51 用 dubbo 就必须搞个 api 模块，里面全是 interface ，别的模块实现接口。不这样没法给别的服务 rmi 调用

其实吧，林子大什么鸟都有，江湖大什么人都有，有时也只能看开点……

拿我项目组一堆沙雕外包来说，就组装 URL 这个很简单的事，老是自己做字符串格式化，结果要么有时多了斜杆，要么有时特殊字符没有转义，总之小毛病不断。你跟他说了无数次用标准库里面的 URL 对象来拼接，过段时间他又自己做字符串格式化。有些人他就是不开窍，这放在高中时代，不就是同一道题一次次重复做错的沙雕吗……你一怼他，他还生气了，能怎么办，就随他去好了，慢慢把他边缘化就是了。

真的恐怖，你们比八股文还八股文。

@Narcissu5 #23 你不写 service ，怎么控制的事务？

没毛病啊，减少服务层赚差价

Java 的教条主义是这样的

任何事情都有成本，既然你的组员能被招入公司，首先是对他的能力和成本公司是认可的，管理层最大的作用是帮助团队提效，而你不仅不想解决办法，帮助组员，只想 fire ，你才是最大的问题，我觉得公司让你担任组长的这层级，没有对你进行过系统培训，而你也没有自主的去学习如何当一个好的管理者。说白了就是草台班子，带领团队，不仅仅是技术向！

难道不是 controller 直接执行 sql 么

看到高赞回复我笑了。看来大家都需要读一下《重构: 改善既有代码的设计》这本书。有时候你嘴里所谓的不遵守“教条”，不过是给后人挖坑罢了