Heim > Backend-Entwicklung > PHP-Tutorial > mvc - php中的Model到底扮演什么角色

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

WBOY
Freigeben: 2016-06-06 20:51:48
Original
1205 Leute haben es durchsucht

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

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

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

    public function delete($id)
    ...
}
Nach dem Login kopieren
Nach dem Login kopieren

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

回复内容:

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

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

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

    public function delete($id)
    ...
}
Nach dem Login kopieren
Nach dem Login kopieren

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

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吧:
mvc - php中的Model到底扮演什么角色
mvc - php中的Model到底扮演什么角色
mvc - php中的Model到底扮演什么角色
mvc - php中的Model到底扮演什么角色

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

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

一个应用程序包括应用程序逻辑和业务逻辑。(参考链接: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(控制器) 共享调用

Verwandte Etiketten:
Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage