Question

我现在已经阅读了一段时间的MVC设计，看来正式的View调用模型中的对象和方法，构建并输出视图。

我认为这主要是错误的。

Controller应该在模型中操作和检索/更新对象，选择适当的视图并将信息传递给它，以便它可以显示。只有粗略和简单的PHP变量/简单if语句才会出现在View中。

如果View获取了需要从Model中显示的信息，那么View中肯定会有很多PHP - 完全违反了分离表示逻辑的点。

Answer 1

没有一种绝对正确的方法可以做MVC。变化是可能的。

例如，Controller不是让View主动查询模型，而是使用某种通知机制通知视图模型中的任何更改。在这种情况下，View只是在监听更新，然后再进行更新。

Answer 2

与所有编程一样，我们需要务实。视图应该只包含表示逻辑。这种逻辑可以非常简单，也可以非常复杂。只要该逻辑仅处理屏幕上显示的内容，打印在报告上等等。

Controller应该在模型中操作和检索/更新对象，选择适当的视图并将信息传递给它，以便它可以显示。

您传递的信息是什么？可能是模型的一个子集。您可以创建一个仅包含视图应该知道的信息的新类，或者只是传递模型并确保只访问适当的数据。无论如何，视图应该可以自由地查询传入的模型以便能够显示视图。

争议的焦点是，如果您从视图中应该能够直接更新模型，绕过控制器。这是实用方面的用武之地。我认为有些情况可以保证直接更新模型。特别是如果你可以使用数据绑定。您可以将文本框分配给模型的属性，并自动进行更新。如果有很多简单的属性设置，这种方法可以在控制器中保存一堆代码。 MVC不是一套完整的规则。正确使用可以产生更好的代码，但如果过于严格使用会导致疼痛和痛苦。

务实！

Answer 3

这可能不是人们称之为“纯粹的”MVC，但恕我直言，只要视图PHP代码不会改变模型，它就不是什么大不了的事。 MVC最重要的规则是模型不了解视图。让视图不了解模型并不重要。

直接使用模型的主要缺点是视图不能与不同的模型一起使用。这很少是一个问题，因为视图几乎总是特定于一种特定类型的模型对象（或其列表）。

Answer 4

对DisgruntledGoat's code snippet的以下修改是否会被视为过于“复杂”？应该将对象传递给视图吗？

<li><?=$item->description?></li>

或者也许？

<li><?=$item->getDescription()?></li>

我见过几个只使用数组的例子： -

<li><?=$item['description']?></li>

Answer 5

MVC并非一成不变的法律。根据您阅读的内容，它可能会有所不同。我个人不允许View直接从Model中读取。

<强>更新这个post也有一些很好的例子。该模型是汽车的引擎与start（）类似的方法，视图是汽车的颜色与paint（）或change（）方法，控制器是驱动程序。我更喜欢让控制器驱动（）汽车并启动（）发动机，而不是让车轮或油漆这样做。

：）

Answer 6

MVC指的是层，而不是组件。因此，它们是比蓝图更抽象的概念。由于实际上不可能完全分离各层（信息必须在它们之间流动），所以它实际上是一个连续体，在另一个极端和官僚类型系统上有意大利面条。你可能想找到这两者之间的某个地方。

我通常不会在控制器视图分离上花费太多精力。模型和（控制器 - 视图）之间的分离更为重要。

Answer 7

我认为你绝对正确 - 视图不应该调用模型中的方法。像其他人所说的那样，MVC存在差异，但它指出逻辑与数据和输出的区别。

通常，您有一个控制器，它是应用程序的起点。在PHP中，这将是您的index.php文件。该文件至少会处理输入数据（即查询字符串或URL参数）。为应用程序的不同部分添加单独的控制器通常是个好主意。

然后，每个控制器只需决定需要显示哪些数据，从模型中获取数据，然后将其传递给视图。在PHP中，您将调用从数据库中获取数据的各种类/方法，并将其存储在变量中。

然后你只需要包含另一个主要包含HTML的PHP文件，但是有一些PHP回显变量。循环也很好。如果你有一个列表，你可能想做这样的事情：

<ul>
<?php foreach ($items as $item) : ?>
  <li><?=$item?></li>
<?php endforeach; ?>
</ul>

MVC：模型视图控制器 - 视图是否调用模型？

7 个答案: