大家工作当中会从controller中抽离出service层来处理业务吗?

公司以前用phalcon的时候,项目用了service层来处理业务,这么做主要是为了避免controller臃肿,只让他处理参数验证和业务分发,而且业务代码可复用。

最近用laravel开发新项目,想要借鉴以前的分层模式,但是发现laravel有form request来处理请求和参数验证,所以想问问大家做的项目有没有独立于controller之外来处理业务逻辑,还有必要抽离出service层吗?

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
最佳答案
controller层接收和转发请求
service层处理业务逻辑
repository层操作模型
traits封装常用组件
4个月前 评论
gema 4个月前
PHPer技术栈 (作者) 4个月前
Hello_Smile 3个月前
PHPer技术栈 (作者) 3个月前
讨论数量: 25
controller层接收和转发请求
service层处理业务逻辑
repository层操作模型
traits封装常用组件
4个月前 评论
gema 4个月前
PHPer技术栈 (作者) 4个月前
Hello_Smile 3个月前
PHPer技术栈 (作者) 3个月前

看你自己或者项目大小 但是我二开的项目都有service 然后现在我自己写也用service

4个月前 评论

写在 model 里就可以了。但是如果要用,建议面向接口,单纯弄个 service 只是把代码挪了个地方,意义不是很大。

4个月前 评论

看业务是不是多端,以后要不要扩展多端
如果需要的话抽离业务逻辑代码到 service 层是有必要的
controller 过于臃肿代码耦合性高对以后的维护和二次开发都不利。

4个月前 评论

小公司更需要设计,全都写在controller里面需求变来变去更难搞,service可以减轻controller的负担,同时提高业务代码复用率,也便于修改

4个月前 评论

我一般都会抽一份service出来的,然后laravel能用上的基本都会用,比如request类,observer类

4个月前 评论

业务比较复杂的我会抽离出来,很多都在model层处理掉了

4个月前 评论

我比较推荐的是写一套模型数据接口,这样的话写数据层接口的只要关心数据操作就行了,至于写业务层的人其实写在controller和service差别不大,因为他只要关心逻辑然后调数据层接口获取数据

4个月前 评论
controller层接收和转发请求
service层处理业务逻辑
repository层操作模型
traits封装常用组件
4个月前 评论
gema 4个月前
PHPer技术栈 (作者) 4个月前
Hello_Smile 3个月前
PHPer技术栈 (作者) 3个月前

service层处理业务逻辑 repository层操作模型

还不会用,改天看看大佬怎么写的

4个月前 评论
如梦又似幻 4个月前
JeffreyBool

我感觉咋写都行,服务要分业务服务和数据服务就行

4个月前 评论

无所谓,老的SSM为了事务可以抽一层,SpringBoot父子容器合二为一了

4个月前 评论

还是分开的好。加个Service 又不麻烦,你又不能确定控制器会不会从 3 个方法变成 30 个方法,最后变成 1W 行代码的大山。

4个月前 评论

工作前一年,基本都不抽的,后来经验多了慢慢知道了,尽量要保证控制器的简洁,带有逻辑的都单独逻辑层,提高代码复用性。要不然项目越做越大,难以维护。model层尽量只做数据库相关的东西,而不能代替逻辑层。(早期用tp的时候,经常把model层当逻辑层来用,实际上是不好的习惯 )

4个月前 评论

用,业务逻辑在service层,方便复用,修改,测试, 如果一个controller的业务很简单,即使查询后返回数据,也可以偷个懒不用

4个月前 评论
fatrbaby

一般我不会,因为抽象个Service出来并不是面向对象,还是面向过程。我一般会DDD设计,这样面向对象性更强一些。

4个月前 评论

我刚开始工作的时候不抽 后面就抽了

4个月前 评论

还是比较推挤抽取service 层的方便 复用,面向接口开发的更好

4个月前 评论

有时间就抽,没时间就放着 :smile:

3个月前 评论

肯定会的

3个月前 评论

最后你可能就是把控制器的代码,剪切到 service 里,,,有什么不一样吗,,,

3个月前 评论
justlovelmn 1个月前
liziyu 1个月前
justlovelmn 1个月前
largezhou (作者) 1个月前
casey

每次看到这个问题都各有所见,也都不乏道理。我觉得代码编写设计尽可能规范就行。可能是语言规范,框架规范,公司规范。我自己也是用了,跟大佬 @PHPer技术栈 差不多,可能需要有这个思想和习惯,但有时候碰到及其简单的业务,也没啥扩展的可能,个人觉得没有必要,假如本来就很小的项目,我是觉得没太大必要做得工程化,理论结合实际才可行。

3个月前 评论

我看了上面大佬的回复发现都在说repository这个, 不过这个的话我记得都要有接口类支撑 /狗头,说到底=service

controller 负责调度分发,拼接参数

request 负责验证参数

service 负责处理部分逻辑

actions 负责处理单一行为

utils 公共工具类

traits 懂得都懂

其他目录与本帖无关

我目前在用的是这个模式,也是在论坛里面看到的 ,

因为就算你用了service模式,不过是把原本在控制器里面的代码都扔给了service而已,

加一个单一行为类来处理部分代码量较多的地方岂不是美滋滋;

3个月前 评论
fatrbaby 3个月前

纯粹就是不想看到控制器有几千上万的代码大山,虽然只是换个地方,但是也方便复用以及一些私有方法的创建,在controller创建私有方法不觉得怪怪的吗

1个月前 评论
颠倒的玉石

c->s->m yyds

1个月前 评论
fatrbaby 1个月前
颠倒的玉石 (作者) 1个月前
fatrbaby 1个月前

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