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的真髓呢？哪位专家能点明。谢谢。
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的真髓呢？哪位专家能点明。谢谢。
你只要知道一点，View layer和Controller本来就该是较为紧密得两个模块，了解一下Controller得历史可能有所帮助，不过一个简单得判断依据是如果View不存在，Controller存在是否有他得意义？ 所以这两层本身就该是较为紧密得耦合Controller是为了让view和下层空间脱藕而存在得
你可以通过使用TreeModel来实现一个JTree来理解MVC。
V-C 弱化Model是MFC采用的
学习!
在mvc模型中，model－view－controller本身就是偶合得非常紧密的，将mvc分离开来，很重要的一点是为了方便为这个model添加功能和外观，也就是说其中的model是相对稳定的，而view和controller是相对可变和多样化的，model更像是一个struct而不是class个人感觉，欢迎拍砖！：）
简单来说就是当view变化时model和control能够不改变或者改动最少
同样当model变化时view能够不改变或者改动最少
所以在写程序时就要尽可能的让view层只做显示界面用不要带上业务逻辑
而在写model时也不要与任何界面元素有关
control是控制层他接受界面请求调用相应的逻辑处理完毕后再通知界面
执行某些任务的代码，不决定用户端的表示，只有一系列方法，纯粹的功能性接口，通过方法获得m的所有功能。
取值方法获得它的状态，修改方法修改它的状态。
一般来说，它要可以登记视图，以便可以把更新通知视图。 类似于观察者模式的被观察者。v：代表多个视图端，多个视图是mvc的原始动机。类似于观察者。c：多个控制器。它与v结合使用，v通过c更新m，同时，c通知登记了的视图刷新。对于.net来说，我认为业务逻辑层就是model层。
--《java与模式》而model分为两种：
1：当一个控制器以独占方式操作模型时，将使用被动模型。控制器将修改模型，然后通知视图：模型已经更改，应该进行刷新（见图 2）。此情况下的模型完全独立于视图和控制器，这意味着模型无法报告其状态更改。2：当模型更改状态而不涉及控制器时，将使用主动模型。当其他资源正在更改数据并且更改必须反映在视图中时，可能会发生这种情况。以股票报价机的显示为例---《使用 Microsoft .NET 的企业解决方案模式 > Web 表示模式 > 模型-视图-控制器》
如果不谈数据感知，其实和三层结构中的前两层（表现层和逻辑层，控制层不是没有，而是不用自己写代码，没怎么提而已）相似，所以，Controller相对来说与View和Model耦合读最低（Controller只是对数据流和指令的传输，大多数中间件实现了该功能），但：View与Model必然存在耦合，一般而言，Model改变可能不影响View，但View增加展现内容，则Model可能不可避免的要变动，并且View和Model需要约定数据的结构其实：真正完全解藕的程序我没看到过，仅仅是让其弱化一些罢了上面没有说数据感知（这是MVC最别于传统的地方）
m提供数据
v展现数据这里m和v的关系在于，m提供什么样的数据，v就只能最多展现这么多数据。在m提供的这些数据的条件下，v要怎么展现，那就是v的自由。
v不能向m要m不能提供的数据，如果出现这种情况，不是mvc结构的问题，是当初的总体设计出了问题。