当前位置:Gxlcms > PHP教程 > 业务逻辑放在controller层好还是model层好

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

时间:2021-07-01 10:21:17 帮助过:195人阅读

一直觉得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》

模式简介

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 划分为多个部分,各有侧重点)。

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

再建一个service层

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

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

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

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

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

齐了,无烦恼。

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

  1. model层:主要是一些数据库的操作;

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

  3. 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,或者执行跳转等等。
但是一旦项目赶进度。直接撸在控制器吧,后期慢慢搬代码。整合

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

人气教程排行