controller层接收和转发请求
service层处理业务逻辑
repository层操作模型
traits封装常用组件
controller层接收和转发请求
service层处理业务逻辑
repository层操作模型
traits封装常用组件
看你自己或者项目大小 但是我二开的项目都有service 然后现在我自己写也用service
写在 model 里就可以了。但是如果要用，建议面向接口，单纯弄个 service 只是把代码挪了个地方，意义不是很大。
看业务是不是多端，以后要不要扩展多端
如果需要的话抽离业务逻辑代码到 service 层是有必要的controller 过于臃肿代码耦合性高对以后的维护和二次开发都不利。
会，很爽。
小公司更需要设计，全都写在controller里面需求变来变去更难搞，service可以减轻controller的负担，同时提高业务代码复用率，也便于修改
我一般都会抽一份service出来的,然后laravel能用上的基本都会用,比如request类,observer类
业务比较复杂的我会抽离出来，很多都在model层处理掉了
我比较推荐的是写一套模型数据接口，这样的话写数据层接口的只要关心数据操作就行了，至于写业务层的人其实写在controller和service差别不大，因为他只要关心逻辑然后调数据层接口获取数据
controller层接收和转发请求
service层处理业务逻辑
repository层操作模型
traits封装常用组件
我感觉咋写都行，服务要分业务服务和数据服务就行
无所谓，老的SSM为了事务可以抽一层，SpringBoot父子容器合二为一了
还是分开的好。加个Service 又不麻烦，你又不能确定控制器会不会从 3 个方法变成 30 个方法，最后变成 1W 行代码的大山。
工作前一年，基本都不抽的，后来经验多了慢慢知道了，尽量要保证控制器的简洁，带有逻辑的都单独逻辑层，提高代码复用性。要不然项目越做越大，难以维护。model层尽量只做数据库相关的东西，而不能代替逻辑层。（早期用tp的时候，经常把model层当逻辑层来用，实际上是不好的习惯 ）
用，业务逻辑在service层，方便复用，修改，测试， 如果一个controller的业务很简单，即使查询后返回数据，也可以偷个懒不用
一般我不会，因为抽象个Service出来并不是面向对象，还是面向过程。我一般会DDD设计，这样面向对象性更强一些。
我刚开始工作的时候不抽 后面就抽了
还是比较推挤抽取service 层的方便 复用，面向接口开发的更好
有时间就抽，没时间就放着 :smile:
肯定会的
最后你可能就是把控制器的代码，剪切到 service 里，，，有什么不一样吗，，，
每次看到这个问题都各有所见，也都不乏道理。我觉得代码编写设计尽可能规范就行。可能是语言规范，框架规范，公司规范。我自己也是用了，跟大佬 @PHPer技术栈 差不多，可能需要有这个思想和习惯，但有时候碰到及其简单的业务，也没啥扩展的可能，个人觉得没有必要，假如本来就很小的项目，我是觉得没太大必要做得工程化，理论结合实际才可行。
我看了上面大佬的回复发现都在说repository这个, 不过这个的话我记得都要有接口类支撑 /狗头,说到底=service
controller 负责调度分发,拼接参数
request 负责验证参数
service 负责处理部分逻辑
actions 负责处理单一行为
utils 公共工具类
traits 懂得都懂
其他目录与本帖无关
我目前在用的是这个模式,也是在论坛里面看到的 ,
因为就算你用了service模式,不过是把原本在控制器里面的代码都扔给了service而已,
加一个单一行为类来处理部分代码量较多的地方岂不是美滋滋;
纯粹就是不想看到控制器有几千上万的代码大山，虽然只是换个地方，但是也方便复用以及一些私有方法的创建，在controller创建私有方法不觉得怪怪的吗
关于 LearnKu
粤公网安备 44030502004330号
推荐文章：