62,615
社区成员
发帖
与我相关
我的任务
分享最近看一些mvc的文章 有许多迷惑不解处 看到了一篇文章写的不错 特转贴 欢迎大家讨论
如何合理设计MVC模块？
--------------------------------------------------------------------------------
model-view-controller是结构是那样的优雅，真的有些把我迷住了，不过，倾心管倾心，疑问管疑问，对于我刚刚接触这个结构的人来说，要它在实现中真正使用还要有许多细节需要了解，比如：
1、大块头的应用大掘三块以后，它们之间还是有紧密的关系，如何在MVC中真正减弱它们的关系呢？我输入一堆信息，这堆信息在输入后应该有一个数据结构来存放，Controller仅仅是把这个结构送给model处理呢？还是自己直接对它分析？如果是直接把数据做成包，送给Model，那么，当屏幕设计涉及到数据结构的变化时，这个改动就通过变动后的参数包波及到Model，这样，这种形式上的逻辑与界面分离不是有些过分了，因为Controller和Model的关系本质上并没有解耦,设计更改过程还要在两处奔波。在第二种情况下，Controller自己直接处理用户输入的数据，把必要的数据按Controller-Model接口要求的格式重新组装，与Model交互，返回业务约束处理后的结果，再作下一步打算，要是这样，我认为Controller的职责变得有些模糊不清，因为它承担了MVC概念中Model职责的一部分业务规则验证工作，就是不承担，它也必须了解业务逻辑的输入数据结构。以便于把输入数据重新组合，这种了解出现二个问题，一是与Model的解耦不彻底，二是Controller所承担的前期的部分业务规则，它的限度在那里，如何确定。
2、上述类似的问题存在View-Model之间。
3、把Controller和View分开的思想，我认为是人类洞察问题能力真正体现。但现在对于我来说，这仅仅是一种感觉而已，还有许多实现的环节没有理解。首先，我想问，View和Controller是否共享屏幕数据结构？这种共享对两者很难从实现在真正分开，是“唇齿相依”。划分它们，我想应该是出于一种设计概念上考虑，更多的是使我们在设计是有更好地对功能划分，并有适当的依据而已。硬把它们做成独自的模块我想在有些时候是得不偿失的。现在许多界面设计工具都把事件和控件紧紧地系在一起，我们应该是出于这个原因。其次，View中存在着与事件相关的知识，我们在Controller中接收事件，但Controller必须需要View的知识（类似于使用Model中的业务逻辑一样），获取事件中的含义，以及动作的目标，从而领会用户的意图，控制程序的流程，它们是如此的紧密结合，以致于诱惑我们让View来做输入这个事情。
上面三方面问题，使模块分离的独立性，自解释，弱耦合的原则得不到真正体现。并可能出现更多的问题，我倒底在什么地方没有真正理解MVC的真髓呢？哪位专家能点明。谢谢。
转自： http://www.umlchina.com/best/g16/g920.htm
--------------------------------------------------------------------------------
model-view-controller是结构是那样的优雅，真的有些把我迷住了，不过，倾心管倾心，疑问管疑问，对于我刚刚接触这个结构的人来说，要它在实现中真正使用还要有许多细节需要了解，比如：
1、大块头的应用大掘三块以后，它们之间还是有紧密的关系，如何在MVC中真正减弱它们的关系呢？我输入一堆信息，这堆信息在输入后应该有一个数据结构来存放，Controller仅仅是把这个结构送给model处理呢？还是自己直接对它分析？如果是直接把数据做成包，送给Model，那么，当屏幕设计涉及到数据结构的变化时，这个改动就通过变动后的参数包波及到Model，这样，这种形式上的逻辑与界面分离不是有些过分了，因为Controller和Model的关系本质上并没有解耦,设计更改过程还要在两处奔波。在第二种情况下，Controller自己直接处理用户输入的数据，把必要的数据按Controller-Model接口要求的格式重新组装，与Model交互，返回业务约束处理后的结果，再作下一步打算，要是这样，我认为Controller的职责变得有些模糊不清，因为它承担了MVC概念中Model职责的一部分业务规则验证工作，就是不承担，它也必须了解业务逻辑的输入数据结构。以便于把输入数据重新组合，这种了解出现二个问题，一是与Model的解耦不彻底，二是Controller所承担的前期的部分业务规则，它的限度在那里，如何确定。
2、上述类似的问题存在View-Model之间。
3、把Controller和View分开的思想，我认为是人类洞察问题能力真正体现。但现在对于我来说，这仅仅是一种感觉而已，还有许多实现的环节没有理解。首先，我想问，View和Controller是否共享屏幕数据结构？这种共享对两者很难从实现在真正分开，是“唇齿相依”。划分它们，我想应该是出于一种设计概念上考虑，更多的是使我们在设计是有更好地对功能划分，并有适当的依据而已。硬把它们做成独自的模块我想在有些时候是得不偿失的。现在许多界面设计工具都把事件和控件紧紧地系在一起，我们应该是出于这个原因。其次，View中存在着与事件相关的知识，我们在Controller中接收事件，但Controller必须需要View的知识（类似于使用Model中的业务逻辑一样），获取事件中的含义，以及动作的目标，从而领会用户的意图，控制程序的流程，它们是如此的紧密结合，以致于诱惑我们让View来做输入这个事情。
上面三方面问题，使模块分离的独立性，自解释，弱耦合的原则得不到真正体现。并可能出现更多的问题，我倒底在什么地方没有真正理解MVC的真髓呢？哪位专家能点明。谢谢。
转自： http://www.umlchina.com/best/g16/g920.htm
...全文
请发表友善的回复…
发表回复
肖尧19 2002-07-10
- 打赏
- 举报
to jokerjava(冷血）
要理解MVC，还是结合实际例子来吧，推荐好文一篇：
http://www.code-labs.com/article/articleinfo.php?id=576
要理解MVC，还是结合实际例子来吧，推荐好文一篇：
http://www.code-labs.com/article/articleinfo.php?id=576
huangzt 2002-07-10
- 打赏
- 举报
MVC只是一种设计框架,并无一定准则可以遵循,应视具体情况而定.
在这种设计中要注意模块分层.对复杂的系统不一定说是只有三块.通过模块的划分解耦.
Java的Swing组件就是按MVC结构设计的,但正如上文所言的情况,使它无法严格的按MVC区分,因此最终被设计成为M-UI结构,在这个例子中,就是将V和C设计成耦合较高的UI,这种设计并没有限制MVC的灵活,反而使其扩展更方便,使扩展组件的人更了解VC的约束关系,因而可以设计出不同风格的组件.
在这种设计中要注意模块分层.对复杂的系统不一定说是只有三块.通过模块的划分解耦.
Java的Swing组件就是按MVC结构设计的,但正如上文所言的情况,使它无法严格的按MVC区分,因此最终被设计成为M-UI结构,在这个例子中,就是将V和C设计成耦合较高的UI,这种设计并没有限制MVC的灵活,反而使其扩展更方便,使扩展组件的人更了解VC的约束关系,因而可以设计出不同风格的组件.
silentmoon 2002-07-10
- 打赏
- 举报
gz
jokerjava 2002-07-09
- 打赏
- 举报
up
jokerjava 2002-07-09
- 打赏
- 举报
这么经典的东西
没人回啊
没人回啊
daehappy 2002-07-08
- 打赏
- 举报
UP!GZ!
jokerjava 2002-07-08
- 打赏
- 举报
up
