发布于 1970-01-01 08:00
  • 6 个回答
    • 我的理解 模型存在 可以为多个 controller(控制器) 共享调用

      2022-11-24 16:53 回答
    • 如果按照目前流行的 api 和restful api 接口的 前后端分离的架构.

      那么php 已经基本沦为数据源提供, 那么 mvc中 php 只处理 model 就是crud 然后 php c 负责调度和处理逻辑 拼装数据. v已经没有了

      前端js 还要在分 mvc 前端model 负责接收数据 同时也负责一些为了页面显示的数据的拼装.

      直接总体就变成 mcmvc

      而且随着前端的发展,针对事件机制的框架 例如mvvm结构 实际变成了mcmvvm

      如果后端是nosql 可能就是mmvvm c也不太需要了. 一些逻辑也放到前端了.

      2022-11-24 16:53 回答
    • 假设:除了网页展现之外,你还需要写CLI脚本做数据库的数据统计。你会怎么设计你的Model同时满足网页展现和数据统计两个任务?

      再假设:你现在用的是MySQL。有一天你需要用PosgreSQL,甚至要开始使用NoSQL。你会怎么设计你的Model让你的总体代码修改量最小?

      回答了这两个问题,我觉得你的问题就解决了。

      2022-11-24 16:53 回答
    • 一个应用程序包括应用程序逻辑和业务逻辑。(参考链接:http://www.wo2jia.cn/home/index.php?c...)

      应用程序逻辑主要是流程控制,如操作账户前要登录、商品添加到购物车时要检查购物车是否有空间,这些是放在Controller中的。而业务逻辑是处理数据的逻辑,如往购物车添加商品、从购物车移除商品等。为了和流程控制分离,我们就把业务逻辑封装起来,称之为模型(Model)。

      那到底什么是“模型”?依照百科的解释

      人们依据研究的特定目的,在一定的假设条件下,再现原型(antetype)客体的结构、功能、属性、关系、过程等本质特征的物质形式或思维形式。

      也就是说模型可以用来描述原型客体,如等比例的航模可以“描述”实际的船只结构和特征。

      业务模型可以这样理解,现实中我们对信息的交换处理,在程序里可以用一些结构化的数据来描述。比如你去超市买东西,就有购物车,然后一件件商品往里面丢,如何抽象模型去描述这个业务?首先也要有一个抽象购物车,在程序里表现形式可以是一个ShopCart类(OO),然后再有一个Goods类,包含商品信息,然后SC提供了几个方法操作Goods。这个过程也可以叫做建模吧。

      建模后,数据如何存储,那就是另外一回事了,你可以存数据库,也可以存文件。严格来说,模型应该是不知道数据如何存储的,需要用 Proxy 来解决。关于ORM,它也是一种模型,你可以细读下这个,想想看。

      说道底,关键在于抽象,多理解概念,脑袋中套用琢磨下就清楚了。

      注:这是我自己的思考过程,受限于水平,一些描述可能不准确,有疑问大可指出,一起讨论,:)

      2022-11-24 16:53 回答
    • 取决于你项目的规模和复杂程度,如果仅仅是简单的数据库CRUD,Model完全被ORM取代没什么问题。

      在我的项目中,因为有模块话以及多种数据来源的复杂性。Model又被细分为三层:

      最上层负责事件调度和缓存调度

      中间抽象出一层,我称之为ModelItem,一个ModelItem的数据来源可能是ORM,也可能是来自Webservice,ModelItem之间可以进行数据与数据间的关系桥接,也就是传统的One2One,Many2Many等关系,但是这种关系并不限于ORM,而是普遍适用于所有数据,所以很有可能一个来自数据库的数据Product可以和来自Taobao Webservice的数据进行链接。

      最下层是数据接口的底层实现,包括ORM和Webservice。

      项目页:https://github.com/AlloVince/eva-engi...

      所以我的结论是:Model的功能包含但并不限于将数据库抽象为对象,如果项目简单,Model可以等价于ORM,如果复杂,Model最好再细分。

      2022-11-24 16:53 回答
    • MVC概念来自传统的桌面软件开发,在那样的环境下,事件发生时,Model可以主动通知View,而这在HTTP协议里是不可能的(长连接comet除外啊)。长期以来,PHP业界对MVC框架中M和C的理解和运用都是不精细的(当然,够用就好,能满足绝大多数业务了)。这导致MC分层不清,PHPer在写代码的时候没有明确的规则,到底业务逻辑放在C里还是M里,常见的问题有:

      1. C层承担职责过多,如,赞一个答案是给对应回答者加声望,写到C里面去了
      2. M层太单薄,就继承一下框架的Model(或者DB类),实现数据库的增删查改
      3. 非数据库操作(如调用微博OpenAPI)只好包装到Util类
      4. 用户输入($_GET,$_POST)全局乱跑,M层和Util里都有

      由于大部分场景下,PHP都用来做Web应用,而且是Database Driven Application,所以,各类Database Driven的快速开发框架也应运而生,比如说,CakePHP的Model类干脆就定义了CURD几个针对数据表的操作,Qcodo直接根据数据表结构自动生成MVC三层的脚手架代码。

      我理解的PHP应用是5层结构,M层应再拆分为Biz Model,DAO,Infrastructure,贴几页我4年前讲过的PPT吧:



      PPT全文下载:"Evolution of Web Application Architectures(ppt2003).ppt" http://vdisk.weibo.com/s/535FV

      2022-11-24 16:53 回答
    撰写答案
    今天,你开发时遇到什么问题呢?
    立即提问
    PHP1.CN | 中国最专业的PHP中文社区 | PNG素材下载 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
    Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有