项目中的 Controller、Service、Models 分别应该怎么分配代码

现在对几个目录及目录下的文件时什么作用还是处于一直半解的状态。
目前了解到Controller不应该写业务逻辑,而是对Service、Models的调用。Models里面主要是数据库的交互?Service才是主要编写业务逻辑的?如何才能使一个项目的目录结构更趋于合理方便维护呢?

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 6

刚好在整理团队开发规范,个人是这么约定目录架构流程规范
https://github.com/alicfeng/TeamStandard
file

4年前 评论
Epona

个人觉得其实不需要service层, 有个Model 和 Controller就够了,加个service层太混乱了。简单的应用的话 随便写吧。 想参考的话 可以看看 Taylor前段时间公开的源代码。laravel-cloud

最后,我觉的这种东西,没有一个什么最好的策略,符合自己的结构即可,没必要完全按照别人的思路。

4年前 评论
JaguarJack 4年前
Epona (作者) 4年前
JaguarJack 4年前
ibucoin

做过几个项目,目前有自己的一套,不要太局限了,自己根据几点来考虑。
我自己的理解是:
1、controller可以直接写业务逻辑,因为你如果controller再做拆分的话,controller层的函数其实并不多。
2、service层主要是业务逻辑复用。如果你写的是crud的操作,就只有那几个地方用到,为什么要用service?等你项目真的代码多起来,需要多处复用的时候,再抽离出一个service。
3、Model层主要做数据转换,数据库的交互,还承担了一部分service的操作。做一个简单的说明:比如我查找到这个模型topic,我需要添加一条评论,这个评论是关联到这篇文章的,我会把操作逻辑写在这个模型里面,这样我要用到的时候就可以直接调用,而不是再注入个service,传入关联id。

Controller和Model已经可以解决项目的问题了,最多加个service来进行逻辑复用。等真的要做到中大型,再来考虑把项目分模块写成package加载,这得架构师思维了,前期我是没能力搞成这样了。

4年前 评论
66

做够十几个项目了
几乎没用过service层,个人感觉controller和model已经够用了
因为做的 API较多所以我一般分为4层
request做表单验证
controller做业务和逻辑
model做数据交互
transformer做数据转换

4年前 评论

model 只做模型关联
controller 使用模型 (尽管这不好 小型项目)
service 重复使用或可能会修改的

这是我的

4年前 评论

说实话,这个还需要看你项目老大或者整个 team 一起规划一下,之前我们公司有个同事只用 controller 连 model 都不用,更别说 service 、 require 的。 这个也看公司项目怎么规定吧,如果没人限定看你自己怎么顺手怎么写了。

4年前 评论

刚好在整理团队开发规范,个人是这么约定目录架构流程规范
https://github.com/alicfeng/TeamStandard
file

4年前 评论

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