1

我正在考虑 MVP - JavaScript 中的被动视图模式的实现。在大多数情况下，视图将是简单的 dom 元素，演示者在其中附加事件侦听器。但是当涉及到像基于 JavaScript 的伪选择框、自动建议或 aria 功能这样的小部件时，这应该是 JavaScript 视图类的一部分还是应该改变视图的逻辑是演示者的一部分？我查看了javascriptMVCs 视图，它们似乎只是模板生成的 html，没有任何逻辑。但对我来说，听 html 选择框的演示者和听带有 javascript 逻辑的伪选择框以模仿真实选择框的演示者之间似乎没有什么不同。两者都不应该关心盒子在内部是如何工作的，他们只需要监听 change 事件。

那你怎么看。视图类的工作是什么。

4

3 回答 3

2

View 对象应该负责绘制自己。被动视图知道如何做事，而不是做什么。它必须负责触发自己的事件。仅仅因为它是一个自定义选择框小部件并没有使它与常规选择框有任何不同。

如果演示者接管了所有视图的职责，那么根本不需要视图。还不如只有一个演示者。

于 2010-07-20T23:32:56.393 回答
1

JavaScriptMVC 的视图是虚拟的客户端模板。它的节点控制器倾向于承担更传统的 View 角色。

于 2010-08-24T21:55:33.290 回答
1

视图的工作是作为视图技术的适配器。在这种情况下，您的视图技术可能是 jQuery over HTML via JavaScript。视图应该被设计成做三件事：

  • 知道事件何时发生，并将这些事件传达给演示者（这可能是间接的，使用像postal.js这样的消息传递框架）
  • 告诉演示者（当被问到时）“x 的值是什么”，其中x是视图中表示的值。
  • 接受来自演示者的消息（通常通过直接方法调用）以更改视图上的值。

被动视图模式中的视图不是有状态的。我再说一遍，视图不代表状态。我的意思是，所有状态和状态转换的知识都由演示者表示。视图只是在演示者和实际视图技术之间提供间接的粘合剂。 除了上述三个要点之外，它没有封装任何关于如何处理其包含的信息的知识。这很重要，因为您永远不应期望视图处于一致状态。您应该始终让演示者负责管理视图的状态。

在此处输入图像描述

上面的堆栈演示了我如何预见模型、视图和演示者的交互，以及它们与视图技术和控制器的关系。

  • 浏览器、HTML 和 DOM（通过 jQuery 管理）是视图技术。这些本质上很复杂，无法代表您的模型。
  • 视图保护您的逻辑不受视图技术的影响。它提供了间接性，因此您可以专注于您的演示者中的普通旧代码。视图应该使用某种消息传递给演示者。这可以防止视图和演示者之间的双向依赖。它还允许多个演示者操作一个视图。
  • 演示者应负责理解视图的抽象性质，并应根据其与视图的接口来管理模型的状态。它能够理解如何从控制器中检索模型，以及如何将模型持久化回服务器。
  • 该模型是特定时间点的状态表示。它还可以作为控制器和演示者之间的 DTO 。在 JavaScript 中，将演示者行为简单地添加到模型中很容易，有时更可取。
  • 控制器协调应用程序内的导航，并负责从表示中抽象出后端服务。
于 2012-03-07T18:50:20.147 回答