你们在用Laravel开发项目的时候有用到Services层吗？

独立的、第三方服务，写Service； 因为有PC端、小程序和APP，所以做了Repository，方便各处调用； 如果个人项目，我一般都是怎么快怎么来 :joy:

controller —处理参数验证 只能调用 logic、service
logic —处理业务逻辑 能调用 logic、service、repository
repository—数据库处理逻辑 只能调用 model
model–定义表名称和 关联关系 如和其他表的一对一 一对多关联
service—第三方服务 请求第三方接口 如oss 上传、微信支付、物流查询、短信服务等等
正常调用关系：
controller >>logic>>repository>>model
controller>>service
注：
业务处理层叫logic，有的公司也会叫它service，如果你把业务处理层叫service，那就把第三方服务叫 common 也可以，只是一个叫法，对代码分层不影响。

以下是我写的项目分层

参考了整洁架构这本书，查询和对比了大量的资料，也在实践出搞了一套自己觉得用着还OK的方式,如果没有泛型的支持，大量的接口和实现文件会很泛滥

以下是我从业这么多年的总结：

技术总结

0. 如果是外包或不紧要的项目，所有功能直接在控制器中写完即可，别追求什么优雅性，自己能看懂就行。如果项目特别庞大，早期就要设计好分层
1. 能不用接口就不用，原因是因为国内的应用更新太快，可能你这个版本设计的接口在下个版本就不适用了。
2. 创建一个自定义的后置中间件，用于对项目的响应格式做约束，同时避免在控制器中大量调用 $this->success(),$this->error()之类的语句，我看过很多项目都是这样搞的，我就想问一句这样写着不烦吗？虽然现在编辑器都自带AI
3. 有错误直接abort或自定义的Exception抛出异常，全局后置中间件进行响应格式输出,PHP不是Go，用了PHP就不要搞那套一层一层返回 [false,’错误消息’]这种方式
4. 如果是自己唯护后端，能写注释尽量写，尤其是我发现我现在记忆力严重衰退
5. 文档写清楚一点，尤其是遇到那种坑逼的前端，一出问题就甩锅给你，出接口前把各种情景测试好，不要嫌麻烦，测试好后前端对接不好就是他的事。这种事逼哪里都有
6. 技术经验是项目堆出来的，读万卷书，不如动手实践一个项目

其它总结

7.老板问这个功能难不难，一定要说难，而且预留的工期一定要久一点，不要装逼给自己挖坑说马上就能解决
8.别和搞技术的人走太近
9.上班就好好上班，管好自己的一亩三分地，别机巴帮别人瞎操心,别人的工资一分不会给你
10.一个领域内深耕你会发现有不一样的收获
11.没事多搞搞副业，如果副业跟你的专业相同，那么精力不会那么分散
12.多存钱，每个人都会有那么几个用钱的坎
13.没了，以上只是我的总结，不是建议

会用。但不滥用。如果是非常简单的 curd，模型或者控制能 hold 住，不会太肥大的话。直接用它们。一般都在肥大之后迁移出去。不要过早的做无效分层。不是 Java