[讨论]如何合理设计MVC模块？

doudoukiki

转个帖，因为作者所考虑的问题也是这段时间一直困扰我的问题，所以转过来给大家讨论讨论，希望有这方面经验的朋友指点迷津。

1. model-view-controller是结构是那样的优雅，真的有些把我迷住了，不过，倾心管倾心，疑问管疑问，对于我刚刚接触这个结构的人来说，要它在实现中真正使用还要有许多细节需要了解，比如：
   
2. 1、大块头的应用大掘三块以后，它们之间还是有紧密的关系，如何在MVC中真正减弱它们的关系呢？我输入一堆信息，这堆信息在输入后应该有一个数据结构来存放，Controller仅仅是把这个结构送给model处理呢？还是自己直接对它分析？如果是直接把数据做成包，送给Model，那么，当屏幕设计涉及到数据结构的变化时，这个改动就通过变动后的参数包波及到Model，这样，这种形式上的逻辑与界面分离不是有些过分了，因为Controller和Model的关系本质上并没有解耦,设计更改过程还要在两处奔波。在第二种情况下，Controller自己直接处理用户输入的数据，把必要的数据按Controller-Model接口要求的格式重新组装，与Model交互，返回业务约束处理后的结果，再作下一步打算，要是这样，我认为Controller的职责变得有些模糊不清，因为它承担了MVC概念中Model职责的一部分业务规则验证工作，就是不承担，它也必须了解业务逻辑的输入数据结构。以便于把输入数据重新组合，这种了解出现二个问题，一是与Model的解耦不彻底，二是Controller所承担的前期的部分业务规则，它的限度在那里，如何确定。
   
3. 2、上述类似的问题存在View-Model之间。
   
4. 3、把Controller和View分开的思想，我认为是人类洞察问题能力真正体现。但现在对于我来说，这仅仅是一种感觉而已，还有许多实现的环节没有理解。首先，我想问，View和Controller是否共享屏幕数据结构？这种共享对两者很难从实现在真正分开，是“唇齿相依”。划分它们，我想应该是出于一种设计概念上考虑，更多的是使我们在设计是有更好地对功能划分，并有适当的依据而已。硬把它们做成独自的模块我想在有些时候是得不偿失的。现在许多界面设计工具都把事件和控件紧紧地系在一起，我们应该是出于这个原因。其次，View中存在着与事件相关的知识，我们在Controller中接收事件，但Controller必须需要View的知识（类似于使用Model中的业务逻辑一样），获取事件中的含义，以及动作的目标，从而领会用户的意图，控制程序的流程，它们是如此的紧密结合，以致于诱惑我们让View来做输入这个事情。
   
5. 上面三方面问题，使模块分离的独立性，自解释，弱耦合的原则得不到真正体现。并可能出现更多的问题，我倒底在什么地方没有真正理解MVC的真髓呢？哪位专家能点明。谢谢。

复制代码

[ 本帖最后由 doudoukiki 于 2007-1-26 02:39 编辑 ]

doudoukiki

沉了

geel

mvc模式并不太适合php web开发。
一般来说controller和view就是同一个东西

115300111

太抽象

wolftooth

搞理论的都是不是做东西的，做东西的理论只做了解，不做研究

wolftooth

最要的是：实用 简便

ftInternet

怎么做是手段．

关键是理解思想．把ＭＶＣ模型的核心思想理解了就行了。

具体怎么操作，看具体情况。总有能用到的时候。