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

@gefangshuai #140 读个鸡毛，不管你写的好不好，到点开除你的时候都是浮云。。。挣钱摸鱼才是正道。。。

看团队，看项目吧

偏教条主义了，我们之前的公司写 service 等各种层级代码的时候，都是直接写实现类+@Component 的，需要单接口多实现的时候再说（但实际上 99%的情况都不需要），与其严格遵循这些所谓的教条，不如把精力都放在用合适的设计模式写好一个系统上，以我们现在公司的屎山代码看，尽管大家都遵循了 mvc 的基本原则，但代码还是非常非常乱，service 层一大堆不明所以的 if-else 嵌套，各种为了缩短工期完成需求写的临时代码，一行注释都没有，相比教条化的写代码，我觉得这种写代码的方式更加致命（我们现在公司代码乱的原因：为了降本增效，几乎没有产品这个职能岗位，都是运营对接开发，运营还经常换人，大部分功能想一出是一出，由于是所谓的敏捷开发，所以工期又被压得很短，到处都是脏乱差的代码，抛开这些直观的因素，才能谈程序员个人的原因）

知道有个项目叫 Spring Data REST 么？

部门有代码规范吗，有培训吗？

不教而杀谓之虐，不戒视成谓之暴。

组织个培训啥的。。

如果后端只有 10 个人在持续写代码，那就不用！
我这边 10 万行有效代码的 Java 项目，是在 controller 直接写逻辑的，也没什么问题。
你们不知道吧，很多需要 interface 的框架，可以直接放 controller 。我连 interface 都不用，还怕在 controller 里面放逻辑？
service 只能项目内服用，controller 可以 api 服用，看实际需要，用 IDEA ，重构是非常方便的。

分层还是好处理些,比如事务加在 service 层

其实在小厂还蛮常见的

分个 service 层就打为教条主义也是难绷，难不成你复用代码直接调 controller 层方法？以我的理解，前后端分离模式下，controller 就是用来做参数校验和预处理的。我也觉得每个 service 都套个 interface 也挺傻逼的，除非你要做单元测试，但是 99% 的公司哪有空让你做单元测试。说实话现在这些样板代码都是代码生成器直接生成的

看 项目周期、团队人数、业务复杂度。
java 不就写业务比较友好，靠得就是 设计模式 + 层层分。
简单业务随便写。

很符合我对 java 的刻板印象

从项目管理的角度出发，我是偏向于 Java 项目（后端）的分层结构。controller 处理请求相关，service 处理业务相关，dao 处理数据库相关。还有 client 、util 、misc 等。这样，从项目初期就能划分好结构，方便后面的维护，包括修改和扩展。

后面开发过 Python 项目，虽然灵活，但是项目发展下去一团糟。例如一个文件实现的微服务，需求增加后，代码量也增加，全塞在同一个文件，即使加了足够的注释，改起来也容易眼花。所以，即使开发 Python 小项目（ web 项目，包括只提供 http 接口的微服务），我也参照 Java 的代码结构，起码把 app 、controller 、service 解耦，维护起来舒服很多，起码减少了文件的代码行数，文件所涉及的功能也清晰。

@zhouxiaoxiao 这取决于你前期是否设定了编码规范，要是前期没有，我不认为直接调用 mapper 有什么问题。

我更怕你这种死板遵循所谓设计模式的同事写的代码，根本看不懂，一层套一层，硬套设计模式，应该 fire 掉你自己

@duzhuo #197 不用编译，页面直接发，多爽，前端展示的页面又看不到 java 代码

@zhouxiaoxiao #21 一股子 Java 味，还演变成教条主义。

有强迫症的话，回家种地。真以为自己写的代码有多大价值。

没中间商链接释放问题怎么处理？

@RepositoryRestResource 了解一下，什么 controller ，service ，都是多余的。

幸好写 go 的人从来没有这方面的固执