mvc 上的一般...控制器应该将数据传递给视图还是视图应该直接从模型中获取它？答案

【问题标题】：General on mvc... should controller pass data to view or view should grab it directly from model?mvc 上的一般...控制器应该将数据传递给视图还是视图应该直接从模型中获取它？
【发布时间】：2010-11-30 15:09:02
【问题描述】：

我正在努力学习并充分理解 mvc 模式并同时学习 php。我决定构建基本的 mvc 框架，以便以后在各种项目中使用。在这里阅读了很多关于 mvc 和模型/视图/控制器之间耦合的帖子后，我有点迷失了。目前我的理解是，在 Web 应用程序控制器中，控制器处理来自浏览器的请求，并在必要时调用方法模型类告诉模型改变其状态。然后控制器实例化适当的视图类，该类将负责显示界面。这是我不明白的一点......

现在控制器应该将适当的模型对象传递给视图，视图应该在需要时从模型中提取所有数据吗？
或者控制器应该从模型中获取数据并将其传递给视图，可能将其全部包装到视图将访问并从那里获取数据的单个包装器对象中？
或者视图应该在需要时简单地实例化适当的模型并直接从模型对象中提取数据？

从我这里读到的

http://www.phpwact.org/pattern/model_view_controller

我倾向于第三个选项，其中控制器不向视图传递任何内容，视图实例化它需要的模型。这是因为：

视图和控制器应该对模型具有相同的访问权限
控制器不应仅仅充当视图和模型之间的中介。

真的有一种正确的方法可以做到这一点，还是取决于项目？另外，您会向对 OOP 有深入了解但对 php 相对较新且对 mvc 架构不太清楚的人推荐什么方法。或者，也许我应该选择我认为正确的任何事情，并从我的错误中吸取教训（虽然我想避免这个；）？

现在，如果我的问题不清楚，请告诉我，届时将尝试更好地解释。我还阅读了很多关于 stackoverflow 的帖子和不同网站上的大量文章，但仍然希望得到帮助，因此提前感谢所有答案.

【问题讨论】：

标签： php model-view-controller

【解决方案1】：

就个人而言，我一直是#2 的支持者。视图不应该关心模型。视图不应该对此进行任何处理。它应该做它应该做的，格式化数据。

控制的基本流程应该是这样的：控制器接收来自浏览器的请求。它处理请求，决定需要什么数据，并从模型中检索它。然后它将数据传递到视图中，该视图格式化数据并显示它。

作为扩展，用户输入在控制器内部进行处理，并在需要时保存到模型中，然后将反馈反馈到视图中，等等。要带走的关键点是处理发生在控制器内部。

【讨论】：

我和马修一起做这个。 Controller 应该对 View 和 Model 之间发生的一切负责。如果不是，那他们为什么称它为“控制器”？ ;P
控制器和视图在 MVC 中根本不应该对话。业务逻辑驻留在模型中，而不是控制器中。按照您的建议进行操作将使所有内容都以控制器为中心，而不是三个独立的部分 - MVC！

【解决方案2】：

就个人而言，我一直是#3 的支持者。视图不应该关心控制器。视图不应该对控制器有任何依赖。它应该做它应该做的事情，显示模型的视图。

控制的基本流程应该是这样的：控制器接收来自浏览器的请求。它对模型进行任何相关的更新，然后选择一个视图。然后将控件传递给视图，视图从模型中获取数据并进行渲染。

作为一个扩展，用户输入可以被认为是模型的一部分，控制器和视图都可以从中读取。要带走的关键点是 Controller 和 View 不应该相互依赖。这就是该模式被称为 MVC 的原因。

现在，就我个人而言，我觉得 MVC 有点太乏味了，所以我通常将 Controller 和 View 混为一谈。但这并不是真正的 MVC。

【讨论】：

但是如果需要 2 个模型，我们该怎么办？我不确定这是否会发生，甚至可能是一个糟糕的架构，但这听起来像是一种可能的情况。
当然。当以单数形式谈论“视图”和“模型”时，我们实际上只是指各个层。实际的实现可能会调用该层内的多个类/对象。例如，“A View”通常是多个部分片段的集合，它们聚集在一起以呈现最终结果。同样，您通常可以在此过程中使用多个模型对象。

【解决方案3】：

Web MVC 和 Desktop MVC 是两种截然不同的野兽。

在 Web MVC 中，视图中的链接调用控制器上的方法，该方法更新模型，然后重定向到适当的视图，该视图打开模型并显示其需要的内容。

在桌面 MVC 中，选项 3 是错误的，因为视图和模型都应该使用相同的引用。在 Web 中，别无选择。

选项 2 不是 MVC。它是 MVP，其中 Presenter 是一个中介。

控制器对模型具有写访问权限；视图只有读取权限。

【讨论】：

我认为这是一个重要的答案，当您传入#2 数据 MVP 时，视图无法更改数据，否则它将具有您提到的写访问权限，我认为从至少对于网络应用来说是不变的点，而应用程序虽然试图达到这个通信路径，但还是有角度的。

【解决方案4】：

这是一个非常有趣的问题。根据我的经验，php 中的大多数实现都将模型变量分配给视图：

$this->view->my_property = $modelObj->property

这是常见的做法。常见的原因是，如果您发送对象，那么您可以调用从视图中修改对象的方法。

//in the controller file
$this->view->myObject = $modelObj;

//in the view file, you could call an object modifying method
$this->myObject->delete();

从视图中修改模型被认为是不好的做法。有些人认为他们不希望他们的设计师能够从视图中调用模型修改方法。

话虽如此。我不同意通常的做法，并倾向于将整个对象分配给视图并从那里显示它。并且只是约束我自己，不要在那里进行操作。

第三种选择是将整个对象分配给视图。但是当从视图中调用它们时，对象中的某些方法会禁用方法。

【讨论】：

这是一个超级杀手锏！优秀的答案！为什么这不是公认的答案？

【解决方案5】：

我认为这只是关于什么是更好的 "push" 或 "pull" 模型的一般争论。没有“绝对”的最佳解决方案。

【讨论】：

【解决方案6】：

我之前有一个非常相似的问题。我觉得这样想很有帮助：

MVC
Model -- Data store, alerts Views of changes
View -- Displays model, provides hooks for user interaction
Controller -- Handles user input

您会在非网络应用程序中更频繁地使用 MVC，在这些应用程序中，许多类同时相互交互。

在 Web 应用程序中，MVC 表示 MVT（模型-视图-模板）

Model -- Strictly a data store, typically an ORM solution
View -- Handles web requests, provides for user input/output
Template -- Actually displays content (HTML, Javascript, etc.)

所以在 Web 应用程序中，表示在模板中处理，应用程序背后的逻辑在视图（或视图调用的类）中处理，模型负责保存数据。

【讨论】：

MVT 的名字很糟糕。其中，View 表示 Controller，或 Controller + View。
MCT怎么样，我的意思是为什么要把控制器拿出来，即使在Web应用程序中它也具有处理用户输入的相同功能

【解决方案7】：

今天有这么多开发人员无法接受 MVC 的敲门，是因为 MVC 的缩写从进入软件开发的第一天起就被错误地表述了，但这个概念在当时和今天都是正确的。既然我是老派的，那我给你解释一下；当您创建对象时，您首先创建一个模型，以便客户可以查看它，一旦获得批准，您将完全控制对象的制作方式。直到今天，产品制造就是这样。

在当今的 Web 应用程序开发中，这样的术语应该是 VCM。为什么！您查看 Web 浏览器上的内容，然后单击一个按钮以执行操作，该按钮称为控制器。控制器提醒模型，这是产生结果的指令或逻辑（即您的脚本）。然后将结果发送回用户以供查看。在软件工程中，您可以将其称为 CMV；因为在编译和安装应用程序之前，用户将无法查看任何内容。所以我们需要一个控制设备（PC）；操作系统作为模型和监视器来查看结果。如果你能理解这些概念，MVC 应该会开始看起来更有食欲。我希望这个概念能帮助人们理解 MVC。

【讨论】：

【解决方案8】：

我倾向于让控制器充当模型和视图之间的中介，但通常这是将三者连接在一起的单行代码。如果您的模型、视图和控制器已正确解耦，那么您使用的差异应该很小。

【讨论】：