现在不少框架都效仿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专门做控制，这样结构也很清晰。
饿哦局的=》我觉得
学习.....大牛任务
