你们在用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

我是完全不用 service层的, 比较倾向于在Model层写function调用.

分不分层都一样最后的都是mvc 只有c

团队开发共同约定高性能架构设计，自己开发随便写，毕竟php做的大多是快速交付项目抢占市场，怎么方便怎么来.一个积分活动的模块结构

业务简单可以不用，如果业务复杂建议还是尽早分层。好处是职责清晰——控制器负责参数校验和数据输出，service负责业务代码、逻辑处理，repository负责数据库层操作，Model层负责定义字段，缺点就是工作量比单纯的mvc要多。如果是多人协作，也适合model-service-repository的分层。

一般寫到service層。。。維護簡單一點。。。其他也不想折騰了

我为了简化 C 层代码量，会增加一个业务层 Services。业务层调用第三方业务或者调用 model 查询/变更数据，第三方我一般写在Libraries，不要过于抽象。不然维护起来也是一拖。我问过很多前端同事，一些组件化的滥用，会让页面维护起来像吃屎一样难受，因为你不知道修改了组件后会影响多少地方。相同的，后端也是一样的。抽离的业务一定要想好是否需要抽离，修改后所有该调用的地方是否都适用。不然还不如把所有代码写在 C 层好维护，就是看起来多了点而已。 举个简单例子，像取消订单，定时器和接口都会调用，抽象到 service 层。那我就不需要写 2 套代码了，并且逻辑有改动我也只用改动一个地方，退款等也一样。总之，看业务是否会存在多出调用也业务需求完全一致的情况下再考虑抽离。

不仅用。而且大量使用。

社区推荐的是 Action 模式，也就是命令模式。

在 AI 越来越强悍的今天，转变开发思路很有必要，大部分代码让 AI 写，而 AI 生成代码往往是单片段、针对具体业务场景的实现，抽象太多反而增加额外设计和协调负担。

在AI辅助开发时代，“先简单写，后抽象，按需复用”是最实用的开发哲学。

复杂就封装，简单就写在 controller 里；多次用就抽 service，一次用就 local function。

服务层不是必需的抽象，而是必要时的工具，不搞“强架构洁癖”，才是AI时代最高效的开发方式。

不同语言和框架有不同写法，Laravel有一种方案是写在表单验证类里，参考自带的登录注册

我个人经验：没有什么完美设计模式，不必纠结过多的分层设计，切合团队规范设计即可，主要原由以下：

1. 从设计模式来看：设计模式目的是为了抽象化代码设计，最大程度复用代码，并是代码更好维护，所以过多的分层设计反而适得其反。
2. 从业务开发来看：逻辑总量不变的情况下，相较于单一分层，多层设计只是将逻辑总量拆分到各个分层文件中，用分层文件数换取代码维护度，业务迭代累积下去，再好的设计，最终也会是屎山。
3. 从团队技术管理来看：团队开发协作，首要是团队技术规范设计，个人分层习惯尽量遵守此项约定，毕竟项目后续迭代维护才是团队重要工作。

我司就是service包揽一切业务，controller和model层负责基础职能工作，没有用repository，取而代之用trait来代替实现辅助查询/辅助业务验证等等。