关于控制器与视图的一个讨论

刚刚在看 一个PHP框架
色色 - 北京(449211678) 11:03:17
看到有个新鲜的东西 与大家讨论下
色色 - 北京(449211678) 11:03:44
在我们当前的框架中 控制器与视图 耦合特别紧密 是吧
色色 - 北京(449211678) 11:04:19
大多数 基本上就是 在控制器里面 校验获取数据 设置到视图
色色 - 北京(449211678) 11:04:30
然后 获取视图去渲染
色色 - 北京(449211678) 11:04:49
而 控制器一般是不能被 重用的是吧
色色 - 北京(449211678) 11:05:05
这个框架 把 视图 分成了2层
色色 - 北京(449211678) 11:05:25
第一个 是 viewModel 另一个是 viewTemplate
色色 - 北京(449211678) 11:06:36
前者 则是处理 把 控制器中的 数据获取,数据填充到视图这部分的逻辑
色色 - 北京(449211678) 11:06:56
而后者则对应 我们现在的模版文件
淡淡定-深圳(236815055) 11:07:21
这样的好处是什么呢
色色 - 北京(449211678) 11:07:28
而 控制器 就成了 校验数据 选择视图的位置
色色 - 北京(449211678) 11:07:50
把 数据获取|处理 放到了 viewModel
色色 - 北京(449211678) 11:07:52
里面
色色 - 北京(449211678) 11:08:25
我当前 没有想好 好处是什么
淡淡定-深圳(236815055) 11:08:46
是不是换模板更快呢
淡淡定-深圳(236815055) 11:08:50
 
色色 - 北京(449211678) 11:08:51
可见的是 控制器更轻量级了
o嘻洋洋o--南昌(821049776) 11:09:00
 
色色 - 北京(449211678) 11:09:03
而 模版 也能重用
sakura-中山(93741852) 11:09:14
YII的控制器就够轻量了吧
色色 - 北京(449211678) 11:09:41
大家都出来 谈谈这种思路的优缺点吧
你知我知-深圳(435188073) 11:11:06
你刚看的是哪个框架
JackChen-北京<[e-mail]> 11:12:58
Joomla里它自己实现的MVC就是这样的
JackChen-北京<[e-mail]> 11:13:02
很早以前就是了
sakura-中山(93741852) 11:13:14
控制器本身就不应该做太多的事情..
JackChen-北京<[e-mail]> 11:13:21
我以前也很纳闷为什么要实现两层东西
sakura-中山(93741852) 11:13:48
控制器甚至只需要做分发和验证就够了
sakura-中山(93741852) 11:14:10
至于获得到的原始数据，再交由下一层处理为格式化好的数据输出到模版。
酒鬼-广州(471535768) 11:14:23
好处很大
酒鬼-广州(471535768) 11:14:37
其实现在的mvc感觉都很假
sakura-中山(93741852) 11:14:39
否则模版层就是纯粹的模版，比如一个smarty什么的了
JackChen-北京<[e-mail]> 11:14:57
数据验证放在数据层model里不是更好吗
sakura-中山(93741852) 11:15:05
不好
sakura-中山(93741852) 11:15:13
比如一些需要过滤的内容
sakura-中山(93741852) 11:15:40
model层只负责CRUD，保证数据的唯一性，但不负责安全性。
JackChen-北京<[e-mail]> 11:15:53
但是按照MVC的结构来说，是应该和在Model里的
酒鬼-广州(471535768) 11:15:53
对， 就要这样
酒鬼-广州(471535768) 11:16:03
分好职责
JackChen-北京<[e-mail]> 11:16:04
我都是放到Model里
sakura-中山(93741852) 11:16:13
当然，也可以在model层再加一个前端，来负责数据的过滤和分发。
JackChen-北京<[e-mail]> 11:16:32
我的Model里是负责业务逻辑的
色色 - 北京(449211678) 11:16:31
fuelphp-v1.1
sakura-中山(93741852) 11:16:34
model层只是一个接口，你面向的是纯粹的接口，不用管里面的实现。
sakura-中山(93741852) 11:16:46
jackchen，YII的model就是负责业务逻辑
sakura-中山(93741852) 11:17:13
应该说，model层实现了业务逻辑所需要所有的数据接口
JackChen-北京<[e-mail]> 11:17:14
是我，我也是这么实现的
JackChen-北京<[e-mail]> 11:17:30
控制器只负责接收数据和渲染模板
sakura-中山(93741852) 11:17:50
至于需要什么，就归控制器，如何格式化数据贵view，如何显示数据归template
sakura-中山(93741852) 11:18:35
比如，我有个数据想更改格式，不如货币要换币种，在view里面做就好了，控制器只提供原始数据就够了
色色 - 北京(449211678) 11:18:54
 
色色 - 北京(449211678) 11:19:32
我也觉得 当前mvc的模式很假
色色 - 北京(449211678) 11:19:43
控制器 和 视图 其实没有分出来
JackChen-北京<[e-mail]> 11:19:48
控制器只负责接收的渲染的好处是，当修改业务逻辑时，只要修改model,修改显示内容时只需要修改view,而controller不需要改动
sakura-中山(93741852) 11:19:57
其实，想想也应该如此，模版选择就应该是view层的事情
JackChen-北京<[e-mail]> 11:20:15
是啊
sakura-中山(93741852) 11:20:15
但是，如果不剥离，更换模版就变成了controller的事情。
sakura-中山(93741852) 11:21:06
controller用途其实只是把数据交给view，然后再由view去负责分发到具体的模版。这样数据和模版完全脱离
sakura-中山(93741852) 11:21:17
也不会有一个东西既要管数据库又要管模版了
色色 - 北京(449211678) 11:21:58
控制器 校验传入的数据是否符合要求 照理说就应该传递给视图对象了
sakura-中山(93741852) 11:22:27
控制器不用负责向下传递的数据吧
色色 - 北京(449211678) 11:22:29
视图对象 根据自身要渲染的东西 去调用不同的model
色色 - 北京(449211678) 11:22:47
控制器 接收 外来的数据
色色 - 北京(449211678) 11:22:53
选择 视图
sakura-中山(93741852) 11:23:00
view为什么要调model
sakura-中山(93741852) 11:23:05
那你还要controller干嘛
sakura-中山(93741852) 11:23:09
纯route啊
色色 - 北京(449211678) 11:23:34
控制器可以 过滤外部传人的数据
色色 - 北京(449211678) 11:23:53
视图 根据自己要渲染的内容去调用 模型
sakura-中山(93741852) 11:23:56
所有的数据交换必须经过controller
色色 - 北京(449211678) 11:24:02
为什么呢
色色 - 北京(449211678) 11:24:19
视图 如果分为2层的话
色色 - 北京(449211678) 11:24:34
1个 是 viewModel 另一个是 纯模版
sakura-中山(93741852) 11:24:41
视图不知道自己需要什么数据，是控制器知道某个请求需要什么数据，然后去和Model层要来数据，交给view层
色色 - 北京(449211678) 11:24:59
viewModel 里面 获取自己需要的数据 然后渲染 纯模版

sakura-中山(93741852) 11:25:09
view层把controller传过来的数据格式化成自己需要的数据在扔给模版。
色色 - 北京(449211678) 11:25:48
中山 你说的似乎更好
sakura-中山(93741852) 11:26:07
view层负责的是格式化数据，controller只负责提供原始数据
色色 - 北京(449211678) 11:26:23
但 控制器 似乎还是有好多事情要做啊
sakura-中山(93741852) 11:26:35
后期或许需求有变动，某些数据不需要了或者需要了哪些，那么只需要改动view就够了。
sakura-中山(93741852) 11:27:05
除非需要的数据是控制器没能提供的，这才需要去修改控制器
色色 - 北京(449211678) 11:27:28
不理解 我
sakura-中山(93741852) 11:29:05
先从纯粹的请求角度来说
1控制器接收到请求
2根据请求的方法来判定需要什么数据
3和Model层交互取得数据
4把数据原封不动的转交给VIEW层
5生命周期结束
色色 - 北京(449211678) 11:29:48
这样一类 控制器就还是必须知道 视图里面的所有东西啊
瓶子-北京<[e-mail]> 11:29:56
驱动层 是属于哪级别的呢?
瓶子-北京<[e-mail]> 11:30:12
model?
sakura-中山(93741852) 11:30:16
可以说，controller对于数据是透明的，它只知道传递数据，至于数据是啥它不管
sakura-中山(93741852) 11:30:40
视图需要什么是根据请求的
JackChen-北京<[e-mail]> 11:30:59
我理解中山的意思
色色 - 北京(449211678) 11:31:10
没理解 吃饭去了啊
JackChen-北京<[e-mail]> 11:31:14
以前的Joomla的实现是像色色说的，可以直接去调用Model层
sakura-中山(93741852) 11:31:33
色色
sakura-中山(93741852) 11:31:42
视图是负责显示数据的
sakura-中山(93741852) 11:32:01
至于显示什么要根据控制器方法。控制器给它什么数据就显示什么数据
sakura-中山(93741852) 11:32:33
这就是看你要把需求建立在视图上还是建立在请求或者说控制器方法上
JackChen-北京<[e-mail]> 11:32:39
色色说的是控制器只负责接收，不负责其它的
JackChen-北京<[e-mail]> 11:32:54
中山说的是控制器不仅负责接收，还要负责数据传递
JackChen-北京<[e-mail]> 11:33:26
前端数据传递
JackChen-北京<[e-mail]> 11:33:34
我更倾向于中山的说法
sakura-中山(93741852) 11:35:21
色色的概念是分模块，各模块之间都可以交互
sakura-中山(93741852) 11:35:44
我的概念是分层，每层对下一层都是透明的
JackChen-北京<[e-mail]> 11:41:46
嗯