JavaScript 中的被动视图

发布于 2024-09-10 20:13:49 字数 431 浏览 6 评论 0原文

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

那你觉得怎么样呢。视图类的工作是什么。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

唐婉 2024-09-17 20:13:49

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

如果演示者接管了所有视图职责，则根本不需要视图。最好只有一个演示者。

回复收藏 0 原文

行雁书 2024-09-17 20:13:49

视图的工作是作为视图技术的适配器。在这种情况下，您的视图技术可能是通过 JavaScript 实现的 jQuery over HTML。该视图应设计为执行三件事：

了解事件何时发生，并将这些事件传达给演示者（这可以是间接的，使用诸如 postal.js)
告诉演示者（当被问到时）“x 的值是多少”，其中 x > 是视图中表示的值。
接受来自演示者的消息（通常通过直接方法调用）以更改视图上的值。

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

在此处输入图像描述

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

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

The view's job is as an adapter to the view technology. In this case, your view technology is likely jQuery over HTML via JavaScript. The view should be designed to do three things:

Know when events occur, and communicate these events to the presenter (this may be indirectly, using a messaging framework like postal.js)
Tell the presenter (when asked) "what is the value of x" where x is a value represented in the view.
Accept messages from the presenter (usually through a direct method call) to change the values on the view.

A view in the passive view pattern is not stateful. I repeat, a view does not represent state. What I mean by this is that all state and knowledge of state transition is represented by the presenter. The view is simply the glue that provides indirection between the presenter and the actual view technology. Beyond the three bullet points above, it does not encapsulate any knowledge of what to do with the information it contains. This is important, because you should never expect a view to be in a consistent state. You should always hold the presenter responsible for managing the state of the view.

enter image description here

The stack above demonstrates how I foresee the model, view, and presenter interacting, as well as their relationship to the view technology and the controller.

The browser, HTML, and DOM (managed through jQuery) are the view technology. These are inherently complex, and incapable of representing your model.
The view protects your logic from the view technology. It provides indirection so that you can focus on plain old code in your presenter. The view should use some sort of messaging in order to communicate back to the presenter. This prevents a bidirectional dependency between the view and the presenter. It also allows multiple presenters to manipulate a view.
The presenter should be responsible for understanding the abstract nature of the view, and should manage the model's state based on its interface to the view. It is capable of understanding how to retrieve a model from the contoller, and how to persist the model back to the server.
The model is a representation of state at a specific point in time. It can also serve as a DTO between the controller and the presenter. In JavaScript, it is easy and sometimes preferable to simply add presenter behavior on to the model.
The controller coordinates the navigation within the application, and is responsible for abstracting the back-end services from the presentation.