如果视图需要访问模型中的数据，您认为控制器应该：
a) 将模型传递给视图
b) 将模型的数据传递给视图
c) 两者都不是；这不应该是控制器的关注点。让视图直接访问模型以检索数据。只让控制器给视图需要的一些参数来过滤模型中的数据。
d) 视情况而定。
e) 以上都不是，但是[...]
谢谢
在 cmets 对用户删除的答案进行了一些辩论之后，也许这需要澄清。我对 MVC 架构的看法偏向于 Zend Framework (php)，其中控制器中的操作默认分配有默认视图。因此，决定哪个视图合适的不是模型，而是控制器。你觉得模型应该规定什么视图是合适的吗？我认为让视图基于模型构建的唯一方法是让控制器将模型传递给视图。是否有其他技术可以让视图在不涉及控制器的情况下访问模型？还是让控制器将模型传递给视图，以便可以根据模型属性构建视图是完全没问题的？
【问题讨论】：
标签： model-view-controller language-agnostic design-patterns
e) 以上都不是；传入视图优化的“ViewModel”。
ASP.NET MVC 中的示例：-
public ActionResult Details(int id)
{
Product p = ProductService.GetProductById(id);
if(p == null) { return RedirectToAction("Index"); }
ProductViewModel model = new ProductViewModel(p);
return View(model);
}
a) 和 b) 都“会”受 d) 约束。永远不会 c)。
通常，ViewModel 只是封装了模型（如果没有发生任何复杂的事情，您的视图可以直接通过 ProductViewModel.Product 访问模型）。但是，如果视图需要对模型执行任何复杂的操作，则由 ViewModel 负责，而不是由 Controller 或 View 负责。
这可以让您的关注点保持良好和隔离。你的控制器并不关心你的视图需要什么特定的数据（除了它渲染产品的一些细节之外），或者特别是你的视图需要什么格式的数据。你的视图不依赖于你的实现细节模型。您的模型不必关心它是如何被查看的。如果您有两个呈现产品的视图（例如 Create、Edit、Summary、MoreDetails 等），这些视图可以具有不同的 ViewModel 以仅公开每个特定视图所需的数据，因此您的视图不会相互依赖。可爱的:)
从不同的角度进一步阅读：-
http://www.thoughtclusters.com/2007/12/datamodel-and-viewmodel/
http://stephenwalther.com/blog/archive/2009/04/13/asp.net-mvc-tip-50-ndash-create-view-models.aspx
http://www.nikhilk.net/Silverlight-ViewModel-MVC.aspx
我认为 ViewModel 是一个特别的 .NET 事物，但我完全看不出为什么该模式不能在 PHP 中使用。
希望这会有所帮助。
【讨论】：
ViewModel在PHP中实现的教程：MVC-meet-the-viewmodel-pattern
理想情况下，它应该“将模型的数据传递给视图”，这样视图就不需要知道模型的任何显式结构，从而更加可重用和设计人员友好。
但实际上，“将模型传递给视图”效果很好。大多数时候，无论如何您都需要一个新视图，因为客户从不共享最喜欢的颜色（如果您知道我的意思:-)，因此视图的可重用性并不能证明需要大量繁琐的代码来将数据从模型复制到视图。
您应该更关心的是控制器本身的模块化，因为许多网站确实共享通用功能（控制器），例如网络论坛或新闻列表，但不具有外观（视图）
【讨论】：
这是晚我知道，但我在我正在处理的项目中遇到了这个问题。我从 a) 开始——为了简单起见——现在遇到了障碍。
我正在尝试这种方法：
e) 以上都不是；传入视图优化的“ViewModel”。
因为它避免了模型类（其实例是“事务对象”）和视图的膨胀。例如，您可能需要渲染具有特定小数位数的数字（这是我现在遇到的问题）。
使用中间“ViewModel”这很容易 - 您只需编写相关的 ViewModel“getXXX” 方法以返回您希望格式化的数字。
如果您只是将模型直接传递到视图中，则每次使用此图时都需要在视图中指定它（与 DRY 相悖 - 不要重复自己），或者，将渲染方法添加到您的模型类（与仅用于一个目的的类相反）。
干杯
【讨论】：
a) 将模型传递给视图
否则控制器会通过筛选模型来操作视图。这就是“b）将模型的数据传递给视图”中会发生的情况。 b) 选项在纯 MVC 模式中甚至没有任何意义。毕竟，模型就是数据。如果模型为了消费而改变，一个视图已经被应用，无论你选择在控制器中做它并将它作为控制器函数传递。当你有不同的看法时会发生什么？控制器是否以不同方式筛选其数据？您很快就会有两个模型视图，控制器子视图和视图本身。
【讨论】：
对我来说就是 e)。
正如这里已经提到的，理想情况下视图和模型是分离的。我更喜欢实现这一点的方式是为模型设置一个 viewHelper。这具有视图可用于获取数据的 API。现在视图不受模型更改的影响，并且视图不需要“获取”模型的内部结构。这些被 viewHelper 隐藏起来。
示例：
class Post {
public function export(ViewHelper $helper) {} // I try to avoid getters when I can
}
class PostViewHelper {
public function getTitle($parameters) {} // title of current post in the loop
}
class PostView {
private $helpers = array();
public function loadTemplate($path) {}
public function addHelper(ViewHelper $helper, $name) {}
public function __get($key) {} // if exists $this->helper[$key] etc
}
在模板中
<h1><?php $this->post->getTitle(); ?></h1>
您可能希望以不同的方式实现这一点。但我的观点是视图和模型是如何解耦的，引入了一个中间 viewHelper 来创建视图/模板 API。
【讨论】：
我认为没有那么复杂。 a 或 b。
控制器的工作是管理关系。它找到模型和视图，并为视图提供完成其工作所需的所有模型数据。而已。 MVC 并没有规定数据采用的确切形式。
(a) 从简单开始。将模型对象直接传递给视图是很自然的。如果你有一个关于 Foo 的页面，只需传递 Foo。
(b) 但有时——而且只是有时——您创建一个值对象/DTO 来将数据获取到视图（上面称为 ViewModel）。 当视图和本机模型不匹配时执行此操作，例如摘要视图。如果视图呈现 1,000,000 个对象的摘要，您不想将视图交给模型对象；您想向视图提供 1,000,000 个对象的摘要。
确切的实现实际上取决于您使用的语言和框架。但我认为这些指南是一个好的开始。
【讨论】：
嗯嗯。
我真的看不出 a 和 b 之间的区别，除了你将如何传递数据的一些技术性问题。
通常您将数据映射与模型中的一些数据一起传递给视图
【讨论】：