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

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

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

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

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

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

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

这是我的

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

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