mvc - php中的Model到底扮演什么角色
从字面上理解，都称其为模型层，什么是模型？大多数Model的定义就像这样
class User extends Model
{
public function add(array $user)
{
// 新增代码
}
public function delete($id)
...
}
Model难道只是个对数据库增删查改接口的封装吗？还有些人认为，Model应该是对数据表的映射，它难道是一种ORM的实现？
回复内容：
一直在用MVC模式编程，突然对其中Model层的定义有些疑惑，要说其它两层把，一个负责展现的视图，一个负责流程的控制，清晰明了，但是其中的Model又指的什么呢？
从字面上理解，都称其为模型层，什么是模型？大多数Model的定义就像这样
class User extends Model
{
public function add(array $user)
{
// 新增代码
}
public function delete($id)
...
}
Model难道只是个对数据库增删查改接口的封装吗？还有些人认为，Model应该是对数据表的映射，它难道是一种ORM的实现？
MVC概念来自传统的桌面软件开发，在那样的环境下，事件发生时，Model可以主动通知View，而这在HTTP协议里是不可能的（长连接comet除外啊）。长期以来，PHP业界对MVC框架中M和C的理解和运用都是不精细的（当然，够用就好，能满足绝大多数业务了）。这导致MC分层不清，PHPer在写代码的时候没有明确的规则，到底业务逻辑放在C里还是M里，常见的问题有：
- C层承担职责过多，如，赞一个答案是给对应回答者加声望，写到C里面去了
- M层太单薄，就继承一下框架的Model（或者DB类），实现数据库的增删查改
- 非数据库操作（如调用微博OpenAPI）只好包装到Util类
- 用户输入（$_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
取决于你项目的规模和复杂程度，如果仅仅是简单的数据库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(控制器) 共享调用