业务逻辑放在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

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

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

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

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

Answer 3

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

Answer 4

怎么分都能说出理由，但 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 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层

Answer 11

TP5的文档建议放在模型

http://www.kancloud.cn/manual/thinkphp5/122950

Answer 12

看你怎么架构你自己的程序，可以放在model层中，那么在设计方法的时候要考虑好拓展性和复用性。放在controller层的话，model层的数据操作就尽可能的原子级别操作。
现在比较喜欢增添一个service层，那么的话可以让controller和model层看起来更好看一些

Answer 13

标准的MVC是这样的。
模型负责数据库读写还有各种业务逻辑。
控制负责接收参数；过滤参数；实例化模型；调用方法；渲染模版输出，或者ajax,或者执行跳转等等。
但是一旦项目赶进度。直接撸在控制器吧，后期慢慢搬代码。整合

Answer 14

放哪的都有 看设计者怎么考虑吧~ 如果还是乱就再抽象一层喽~

Answer 15

其实MVC搞多了搞脑子了，只要能够方便部署和快速响应，用不用MVC都没啥关系，都是人为的复杂化而已

Answer 16

通用分层(MVCS):
分发入口 action(可裁剪)
控制逻辑 controller
服务业务 service
数据模型 model

业务复杂,耦合度高,多系统融合频发等情况,最好将程序的逻辑架构整理清楚,才能更好的迭代,维和,定位,扩展.

不然后期打补丁式的迭代形式,会越来越糟心.