在我的应用程序中，我有一个 View 对象，它可以通过 load($template) 模板来准备好使用 render() 方法进行渲染。
在我读过的所有关于Views 的文章中，有时我看到人们以我目前的方式做事，而其他时候我看到人们在做类似以下的事情
class ProductView extends View {
}
class CheckoutView extends View {
}
每页有一个单独的View。
两种方式的优缺点是什么？
任何建议都会非常感谢。
【问题讨论】：
标签： php templates model-view-controller view
视图不应该是“加载模板”。如果视图中有
$this->load('header');之类的代码，则违反SRP。查看（有时）使用模板为用户创建响应，但不应创建它们。
在您将遇到的大多数关于视图的文章中，您将阅读 Rails（及其克隆）对视图的解释。在 RoR 中，您没有视图。只是一个美化的愚蠢模板。
表示层的结构使您最好在控制器和视图之间建立 1:1 的关系。每个视图负责处理由用户输入触发的响应。因此：您的页面通常会有一个每个执行时间的视图。
在更复杂的情况下，您可能需要研究composite view 的概念。这种方法使您可以将表示逻辑分成更小的块。如果您使用ViewModel，这也使您的代码结构更加容易。
底线是：如果您对整个应用程序只有一个视图，那么您做错了。
【讨论】：
ViewHelpers，所以在我的新Product 视图中，如果该视图需要ViewHelper，它是否应该具有private $productHelper 之类的属性？
每页一次浏览绝对是最适合网络的。请注意，我的意思不是每个控制器一个视图，而是每个不同的页面。您希望拥有可以被不同视图调用的不同模板（例如页眉、页脚或导航栏）。
例如，在BlogPostView 中，您将拥有：
$this->load('header');
$this->load('post', $data);
$this->load('footer');
然后渲染它：
$this->render();
【讨论】：
View 的最大优势是什么？我最近遇到了ViewHelpers，如果我每页有一个单独的View，那么将特定的Helpers 分配给每个View 会更容易我想，对吗？
它没有“唯一真正的解决方案”。 但对我来说，视图必须尽可能简单。比如 printf 函数。你想扩展 printf 行为吗？我认为没有！
【讨论】：
ViewHelpers 提供 View 对象？在View 中可能有ViewHelperFactory？