一直觉得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有了更深的认识!
回复内容：
一直觉得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有了更深的认识!
放在model层，如果需要多个model，则在controller调用，model的接口粒度做好就行了，controller只是负责调用几个model通信而已
我是放在Repositories，Model只做ORM关联以及sql查询之类的。
Controller 只处理请求(请求的数据做校验)和跳转。
框架是Laravel（看到tp好多都是写在c层）。
怎么分都能说出理由，但 MVC 作为一个久经考验的架构模式，其不同组件的职责是有相当明确的标准的，不妨参考一些架构模式相关的书籍中对 MVC 的描述，看看他们当初划分职责时是有着什么样的考量：
后文内容节选、翻译自《PATTERN-ORIENTED SOFTWARE ARCHITECTURE》
模式简介
适合应用该模式的环境：
解决的问题
总结如下几点：
用户界面通常非常容易变动（新功能、客户改需求等等）
界面经常会需要为同一个功能提供多种不同的使用方式（鼠标右键、菜单栏、快捷键、浮窗）
界面和功能结合紧密的程序维护起来通常非常昂贵困难，且很难达到想要的灵活性（要求同一份数据可以用两种不同的图标展示、要求很容易对用户界面做出改变甚至是在运行时即时作出）
应用后的效果
优势
同一个 Model ，可以对应多个 View MVC 严格分开了 Model 和 UI 组件，因此对于一个 Model ，可以有多个不同的 View 对应它。在运行时，多个 View 甚至可以同时打开，或是动态的打开关闭。
View 可以同步更新 Model 的“变动通知机制”可以保证 Model 变动时，与之相关的界面可以及时给出反应。
“可插拔”的 view 和 controller MVC 这三种概念上的区分，让你可以把与 Model 对应的 View 和 Controller 组件更换掉，甚至是在运行时这么做都没问题。
因为 Model 部分和 UI 相关的代码完全无关，想要移植一个 MVC 程序到新的平台，不需要对核心功能部分做改动，只需要为新平台重新编写 View 与 Controller 即可。
为“框架”的产生提供了可能，可以基于这个模式建设出一些应用程序框架。
缺陷（喵一眼就行了）
增加了复杂度，某些情况下 MVC 不一定是最好的实现交互式程序的方式。
别喵了，懒得翻了，这部分内容与现在被熟知的 MVC 已经离的有点远了
淡扯远之前赶紧收尾。。。
尽管大众对 MVC 的理解到现在有了很多改变（这书快赶上我年龄了），但从前面也可以看到它一以贯之的核心目标：解耦 “Model” 和 “View & Controller”
功能和数据扔进 Model ，View 和 Controller 构成 UI 。这是实践经验总结出来的规矩的结果。
为什么要分开才是重点，现在的系统的交互界面相对于系统功能、数据来说太不稳定，分开它们，可以保证界面的频繁变动不对稳定的功能数据造成影响。由此给系统提供许多优越的性质。
所以决定一部分代码写在哪里之前，不妨简单问几个问题：
如果老板明天说系统的前端要从浏览器换到手机应用，它是能保留在服务器不更改的那部分么？
1 还不能确定的话，考虑这个（砍死老板不是选项）：如果老板后天说客户喜欢复古，不要手机应用了，要用命令行操作一切。这部分代码还有继续实现的必要么？
答是的话，它应该归于 model 范畴，但仍可以继续细化（如其它答案说的将 model 划分为多个部分，各有侧重点）。
架构提供了一个极好的起点，但从不是设计的终点，项目演化的过程中见招拆招了。或是你能预判可能出现的问题，提前防范，这也是经验丰富的人的价值所在，需要逐步积累。
再建一个service层
标准的mvc模式
业务逻辑放model
简单调用整合放controller
视图显示放view
实际开发根据实际情况变动
ps:我不知道为啥那么多人说controller
感情你的业务逻辑都是放在controller？那太混乱了
tp有个逻辑层'logic'。默认没有，手动添加。
对外用controller
逻辑用logic
数据处理用model
齐了，无烦恼。
可以给你参考下，现在所做项目的模式，希望有帮助到你！用的是tp3.2.3版本的，项目的大致架构是这样的：
model层：主要是一些数据库的操作；
logic层：我们将业务逻辑放到这一层作统一的处理，通过事务的方式来管理，涉及多表操作的问题，这样整体就比较清晰；这里说明下，logic会调用model的单一数据操作；
controller层：接收和处理数据，单一业务，直接调用model的数据操作就能完成，涉及多个数据表操作的，就调用logic层
肯定是controller呀
controller比较合适
当然是写在controller。用spring这样的ioc容器给controller分层，比如分成service层和dao层
TP5的文档建议放在模型
http://www.kancloud.cn/manual/thinkphp5/122950
看你怎么架构你自己的程序，可以放在model层中，那么在设计方法的时候要考虑好拓展性和复用性。放在controller层的话，model层的数据操作就尽可能的原子级别操作。
现在比较喜欢增添一个service层，那么的话可以让controller和model层看起来更好看一些
标准的MVC是这样的。
模型负责数据库读写还有各种业务逻辑。
控制负责接收参数；过滤参数；实例化模型；调用方法；渲染模版输出，或者ajax,或者执行跳转等等。
但是一旦项目赶进度。直接撸在控制器吧，后期慢慢搬代码。整合
放哪的都有 看设计者怎么考虑吧~ 如果还是乱就再抽象一层喽~