php activerecord,ActiveRecord下的model作用

现在不少框架都效仿ROR的ActiveRecord，将model直接作为数据库交互层。而许多业务大都不止针对一张表，有的还包含数据库之外的逻辑，那么我只好把这些业务逻辑放在控制器里处理。

这是不是违背了控制器的原意---连接模型和视图的桥梁

应不应该在数据模型和控制器之前再增加一个层?

大家是怎么做的？ 数据库查询和业务调用都混在model里? 有框架能规避能规避这一点吗?

回复讨论(解决方案)

ORM ？

简单的说，ORM 是把数据库中的关系数据映射称为程序中的对象

在 MVC 中 M、V、C 间并无确定的分工界限

所以在 C中完成部分的乃至全部的业务逻辑都是不违规的

就如同将连续的数据离散化一样，选择不同的阀值，就可得到不同的结果。

我以为基于 ORM 的框架只是提供了一个雏形，应用的具体的项目时还需要进一步扩展

鉴于应用项目的不可预知性，大多 ORM 都没有提供关联或只提供一个接口

所以将 model 从基于 table 改为基于 view 比较好(当然 view 也是不可预知的)

学习。

现在不少框架都效仿ROR的ActiveRecord，将model直接作为数据库交互层。而许多业务大都不止针对一张表，有的还包含数据库之外的逻辑，那么我只好把这些业务逻辑放在控制器里处理。

这是不是违背了控制器的原意---连接模型和视图的桥梁

应不应该在数据模型和控制器之前再增加一个层?

大家是怎么做的？ 数据库查询和业务调用都混在model里? 有框架能规避能规避这一点吗?

饿哦局的可以把数据库专门做一层封装，而model负责处理业务逻辑，需要处理数据的时候调用封装好的数据库模块，这样数据库模块也可以通用化给不同的model调用，而controller专门做控制，这样结构也很清晰。

现在不少框架都效仿ROR的ActiveRecord，将model直接作为数据库交互层。而许多业务大都不止针对一张表，有的还包含数据库之外的逻辑，那么我只好把这些业务逻辑放在控制器里处理。

这是不是违背了控制器的原意---连接模型和视图的桥梁

应不应该在数据模型和控制器之前再增加一个层?

大家是怎么做的？ 数据库查询和业务调用都混在model里? 有框架能规避能规避这一点吗?

饿哦局的可以把数据库专门做一层封装，而model负责处理业务逻辑，需要处理数据的时候调用封装好的数据库模块，这样数据库模块也可以通用化给不同的model调用，而controller专门做控制，这样结构也很清晰。

饿哦局的=》我觉得

学习.....大牛任务

本文原创发布php中文网，转载请注明出处，感谢您的尊重！