php - 业务逻辑放在controller层好还是model层好

Question

一直觉得model层只用来操作数据,很多业务的处理放在controller,有种说法叫业务逻辑更适合放在model层,不知道哪种处理更好!
看了tp5.0,好像把业务逻辑放在了model,然后看了一些贴,好多说业务逻辑放在model更好.
链接:https://ruby-china.org/topics/19292

业务逻辑放在model有个问题:好多时候一个业务逻辑需要多个model的配合或者说调用,像CI,model与model之间的互相调用就比较困难,还有model调用model总觉得不好!

看了这个回答:
放在model层，如果需要多个model，则在controller调用，model的接口粒度做好就行了，controller只是负责调用几个model通信而已.

觉得业务逻辑放在model比较好:controller来处理接受参数,传递参数,包括从前端取,给前端,也包括从model取返回值,给model参数,这样controller很清楚的做一件事情(取,给,差不多就是路由,逻辑交个model).

感谢很多人的回答,对mvc有了更深的认识!

Answer 1

放在model层，如果需要多个model，则在controller调用，model的接口粒度做好就行了，controller只是负责调用几个model通信而已

Answer 2

我是放在Repositories，Model只做ORM关联以及sql查询之类的。
Controller 只处理请求(请求的数据做校验)和跳转。
框架是Laravel（看到tp好多都是写在c层）。

Answer 3

怎么分都能说出理由，但 MVC 作为一个久经考验的架构模式，其不同组件的职责是有相当明确的标准的，不妨参考一些架构模式相关的书籍中对 MVC 的描述，看看他们当初划分职责时是有着什么样的考量：

后文内容节选、翻译自《PATTERN-ORIENTED SOFTWARE ARCHITECTURE》

模式简介

MVC 模式把一个交互式程序分成了三个组件。 Model 包含了核心的功能和数据。 View 显示信息给用户。 Controller 处理用户的输入。 所有的 View 和 Controller 协作构成了用户界面。另有一个“变动通知机制”（意译，后文提到实现时可用订阅模式即观察者模式）来确保 UI 和 model 之间的一致性。

适合应用该模式的环境：

有着灵活多变的人机交互界面的交互式程序。

解决的问题

总结如下几点：

1. 用户界面通常非常容易变动（新功能、客户改需求等等）

2. 界面经常会需要为同一个功能提供多种不同的使用方式（鼠标右键、菜单栏、快捷键、浮窗）

3. 界面和功能结合紧密的程序维护起来通常非常昂贵困难，且很难达到想要的灵活性（要求同一份数据可以用两种不同的图标展示、要求很容易对用户界面做出改变甚至是在运行时即时作出）

应用后的效果

优势

1. 同一个 Model ，可以对应多个 View MVC 严格分开了 Model 和 UI 组件，因此对于一个 Model ，可以有多个不同的 View 对应它。在运行时，多个 View 甚至可以同时打开，或是动态的打开关闭。

2. View 可以同步更新 Model 的“变动通知机制”可以保证 Model 变动时，与之相关的界面可以及时给出反应。

3. “可插拔”的 view 和 controller MVC 这三种概念上的区分，让你可以把与 Model 对应的 View 和 Controller 组件更换掉，甚至是在运行时这么做都没问题。

4. 因为 Model 部分和 UI 相关的代码完全无关，想要移植一个 MVC 程序到新的平台，不需要对核心功能部分做改动，只需要为新平台重新编写 View 与 Controller 即可。

5. 为“框架”的产生提供了可能，可以基于这个模式建设出一些应用程序框架。

缺陷（喵一眼就行了）

1. 增加了复杂度，某些情况下 MVC 不一定是最好的实现交互式程序的方式。

2. 别喵了，懒得翻了，这部分内容与现在被熟知的 MVC 已经离的有点远了

---

淡扯远之前赶紧收尾。。。

尽管大众对 MVC 的理解到现在有了很多改变（这书快赶上我年龄了），但从前面也可以看到它一以贯之的核心目标：解耦 “Model” 和 “View & Controller”

功能和数据扔进 Model ，View 和 Controller 构成 UI 。这是实践经验总结出来的规矩的结果。

为什么要分开才是重点，现在的系统的交互界面相对于系统功能、数据来说太不稳定，分开它们，可以保证界面的频繁变动不对稳定的功能数据造成影响。由此给系统提供许多优越的性质。

所以决定一部分代码写在哪里之前，不妨简单问几个问题：

1. 如果老板明天说系统的前端要从浏览器换到手机应用，它是能保留在服务器不更改的那部分么？

2. 1 还不能确定的话，考虑这个（砍死老板不是选项）：如果老板后天说客户喜欢复古，不要手机应用了，要用命令行操作一切。这部分代码还有继续实现的必要么？

答是的话，它应该归于 model 范畴，但仍可以继续细化（如其它答案说的将 model 划分为多个部分，各有侧重点）。

架构提供了一个极好的起点，但从不是设计的重点终点，项目演化的过程中见招拆招了。或是你能预判可能出现的问题，提前防范，这也是经验丰富的人的价值所在，需要逐步积累。

Answer 4

可以给你参考下，现在所做项目的模式，希望有帮助到你！用的是tp3.2.3版本的，项目的大致架构是这样的：

1. model层：主要是一些数据库的操作；

2. logic层：我们将业务逻辑放到这一层作统一的处理，通过事务的方式来管理，涉及多表操作的问题，这样整体就比较清晰；这里说明下，logic会调用model的单一数据操作；

3. controller层：接收和处理数据，单一业务，直接调用model的数据操作就能完成，涉及多个数据表操作的，就调用logic层

Answer 5

再建一个service层

Answer 6

标准的mvc模式
业务逻辑放model
简单调用整合放controller
视图显示放view

实际开发根据实际情况变动

ps:我不知道为啥那么多人说controller

感情你的业务逻辑都是放在controller？那太混乱了

Answer 7

tp有个逻辑层'logic'。默认没有，手动添加。
对外用controller
逻辑用logic
数据处理用model

齐了，无烦恼。

Answer 8

肯定是controller呀

Answer 9

controller比较合适

Answer 10

当然是写在controller。用spring这样的ioc容器给controller分层，比如分成service层和dao层