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

我目前是把一些自定义的类型,比如说对Easysms的封装放在Services里面,还有自定义上传类也是放在Services层里面

没有使用repository,感觉很麻烦,也没必要

并没有严格把控制器中的所有业务都抽象到Services层内,Services层现在更多是当成是一些比较复杂的业务封装。

说说你项目是怎么管理的

《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 18

以下是我写的项目分层

Laravel

file

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

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

技术总结

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

其它总结

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

3周前 评论
ononl 2周前
xujinhui 2周前
Mutoulee

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

3周前 评论

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

3周前 评论

以下是我写的项目分层

Laravel

file

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

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

技术总结

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

其它总结

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

3周前 评论
ononl 2周前
xujinhui 2周前
JaguarJack

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

3周前 评论
Epona

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

2周前 评论
yourself

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

2周前 评论

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

file

2周前 评论

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

2周前 评论

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

2周前 评论

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

2周前 评论

不仅用。而且大量使用。

file

file

2周前 评论
jiangehenpi 2周前
Cooper

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

2周前 评论

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

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

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

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

2周前 评论
唐章明

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

2周前 评论

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

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

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

2周前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!