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

[weixin_38066328]

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

[weixin_38112805]

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

[weixin_38095150]

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

[weixin_38093507]

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

[weixin_38084345]

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

[weixin_38077477]

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

[weixin_38066359]

个人觉得其实不需要service层， 有个Model 和 Controller就够了，加个service层太混乱了。简单的应用的话 随便写吧。 想参考的话 可以看看 Taylor前段时间公开的源代码。laravel-cloud。 最后，我觉的这种东西，没有一个什么最好的策略，符合自己的结构即可，没必要完全按照别人的思路。