欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

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

程序员文章站 2022-05-31 20:41:22
...
一直觉得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

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

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

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

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

相关标签: php