哪个MVC图是正确的？ （networking应用程序）
哪个MVC图是正确的？ 每个都有不同的箭头…
图1
图2
http://blog.stannard.net.au/blog/media/simple-mvc-framework/mvc.gif
图3
图4
http://java.sun.com/blueprints/patternshttp://img.dovov.commvc-structure-generic.gif
图5
http://www.shopno-dinga.com/dustbin/mvc.png
他们都是。
MVC是一个模糊的模式。
我对MVC的看法是：
调节器
对象具有一组模型，并具有查看和编辑模型的方法。 它与模型交谈并返回视图的实例，并在模型上应用模型。
视图
是否附加了模型的定义，只是一组显示特定模型的function。
模型
封装数据。 有返回状态和改变状态的方法。
//Controller import Views class Controller private Models //View import Model class View //Model class Model 模型不需要知道关于视图/控制器的任何信息。 视图需要知道模型的定义。 控制器需要拥有模型，并需要了解Views的定义。
你可以更紧密地把它们联系起来，那是可选的。
严格来说，MVC是一种过时的模式。 粗粒度的说法，它引入了视图和模型之间的依赖关系，因为模型直接更新视图状态（ http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm ），如图所示在图4中，你看到Model和View之间有直接的交互作用，根据MVC原来的历史公式，这是不可取的。 事实上，今天我们已经修改了MVC的版本，有时候我们会描述MVP并将其称为MVC。 首字母缩略词“MVC”已经被使用了很多的自由，任何你有三个元素称为模型，视图和控制器的东西基本上是MVC，尽pipe实现的细节和责任定义。 MVC和MVP之间的区别是非常微妙的，当你描述它们，并且驻留在View和Presenter（Controller）职责的定义中。 事实上，Martin Fowler几年前给了MVP（和MVC）他的再见，我们可以从他的angular色中find一个“新的“模式称为演示模型（见http://martinfowler.com/eaaDev/PresentationModel.html ）或PM。 微软已经为其WPF和Silverlight技术定义了另一种称为Model-View-View-Presenter或MVVM的模式（参见http://msdn.microsoft.com/en-us/magazine/dd419663.aspx ），该模式具有Presentation Model作为他的灵感。 我想你可以看看所有这些人，看看他们有多相似（不同）。 在我看来，基本思想是Presentation数据和行为保持在Presenter中，Model不知道View（所以图4closures，甚至是MVC），你应该可以改变View（或者支持不同的View实现）以无痛的方式与Presenter和Model分离。 演示模型可以提供这一点，是有效和彻底的使用现有技术来实现。
其实有一个小的差异。
有两种types的模型：主动模型和被动模型：第一种有通知机制，第二种只是不知道在MVC中使用。
第一个和第四个图表示使用主动模型的MVC。
更多关于它，你可以在这里阅读。
图1和4是正确的MVC模式。 其余的更接近MVP模式。
虽然在一个web MVC中，你有一个被动模型，并且由模型视图来拉动变化，而不是被模型（观察者模式）所推动。
他们中没有一个是错的，但是对于基于MVC和客户端MVC的Web（请求/响应）有一个不同的方法。
在Web环境中，控制器负责处理用户请求，修改模型（如果适用），find正确的视图，将该模型信息分配给视图并将其返回给用户。
在对原始MVC模式（对话桌面应用程序）的更直接的解释中，模型在更改时直接更新视图，并且控制器处理用户input和应用程序逻辑，从而相应地更新模型。 但是，这对于普通的Web应用程序来说并不起作用，因为HTTP是无状态的，并且没有使用任何其他更新的技术（比如评论中提到的长轮询Ajax或websockets），服务器不能真正地通知客户端模型中的变化。
图2，图3和图5对于MVC是准确的。 向控制器发送请求时，使用模型执行操作，然后回应。
