php中的Model到底扮演什么角色

八方名动
  • 518

一直在用MVC模式编程,突然对其中Model层的定义有些疑惑,要说其它两层把,一个负责展现的视图,一个负责流程的控制,清晰明了,但是其中的Model又指的什么呢?

从字面上理解,都称其为模型层,什么是模型?大多数Model的定义就像这样

class User extends Model
{
    public function add(array $user)
    {
        // 新增代码
    }

    public function delete($id)
    ...
}

Model难道只是个对数据库增删查改接口的封装吗?还有些人认为,Model应该是对数据表的映射,它难道是一种ORM的实现?

回复
阅读 15.2k
6 个回答

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吧:
ScreenHunter_002.jpg
ScreenHunter_003.jpg
ScreenHunter_004.jpg
ScreenHunter_005.jpg

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

AlloVince
  • 271

取决于你项目的规模和复杂程度,如果仅仅是简单的数据库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最好再细分。

lanisle
  • 517

一个应用程序包括应用程序逻辑和业务逻辑。(参考链接:http://www.wo2jia.cn/home/index.php?c...

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

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

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

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

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

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

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

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

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

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

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

如果按照目前流行的 api 和restful api 接口的 前后端分离的架构.

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

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

直接总体就变成 mcmvc

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

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

我的理解 模型存在 可以为多个 controller(控制器) 共享调用

宣传栏