问题结构化 JavaScript（视图和模型逻辑分离）

Posted 2023-02-26

【中文标题】问题结构化 JavaScript（视图和模型逻辑分离）

【英文标题】：Issue structuring JavaScript (separation of view and model logic)

【发布时间】：2011-04-29 05:45:38

【问题描述】：

我正在为一个网站（目前，我正在制作一个原型）开发一个大量 javascript 的作品（使用 jQuery）。

总结一下我在做什么，我有一系列“图标”。目前，每个图标都是一个图像。我也有一系列的“桶”。这些图标都从一个存储桶开始。用户可以创建新的存储桶并将图标从存储桶拖到存储桶。这些图标也可以通过单击来打开和关闭（尽管它们仍保留在它们的存储桶中）。

我目前一切正常，但是目前基本上是一堆 img 元素从 div 移动到 div。当我准备好开始实现服务器端逻辑时，我需要一种方法来将正在发生的事情传达给服务器。

我需要一个“模型”对象来反映视图的情况。如果当用户准备好将数据发送回服务器时，我会有一个可以序列化的对象来表示我需要的东西，那就太好了。例如，如果用户将 email.png 图标拖到了 Options 存储桶中，我希望它反映在模型对象中（即 'options': ['email'] ）。

问题是，我所有的逻辑都是基于事件发生的。当用户将图标拖到 div 时，会在 img DOM 元素上触发一个事件，我不确定如何访问它的模型来更新它。我唯一能想到的就是解析 img src 并使用它来找出模型选项的名称，但这是一个非常笨拙和不优雅的解决方案。

有什么想法吗？

【参考方案1】：

您可以通过将根对象附加到 DOM 中的某些内容来维护原始对象模型或对象图，或者使用jQuery data system 将其保留在其中。

甚至将您的 UI DOM 元素引用到这个集中式模型中，以帮助降低两个不同模型的复杂性。

jQuery plugins 在 jQuery 数据系统中以您寻求的方式集中状态并不罕见。

原始 JavaScript

document['myObjectGraph'] = 
    first: 1,
    second: 'two,
    images: [
        document.getElementById('img1'),
        document.getElementById('img2')
    ],
    items: [
        'a',
        'b',
        another =  /* building out the model...*/ ;
    ] 
;

或jQuery数据系统（相同的想法）

jQuery.data(document.body, 'myObjectGraph', 
    first: 1,
    second: 'two,
    images: [
        $('#img1'),
        $('#img2')
    ],
    items: [
        'a',
        'b',
        another =  /* building out the model...*/ ;
    ]         
);

这实际上在一个地方创建了一个可管理的模型（您可以选择其设计）——它代表了您的图标、存储桶和其他任何东西的状态；它可以使用JSON 序列化并通过ajax 调用发送到服务器；并且您的 UI 元素甚至可以从中重建/刷新。

这个想法伴随着额外的间接成本和保持原始模型与 UI 模型同步的努力。

【参考方案2】：

你可以使用元素的 id 或 class 属性来存储模型的名称吗？然后，您可以为每个字符串指定您想要的任何字符串，而不是尝试关闭 src 属性。

【参考方案3】：

您可以将图标留在存储桶中，然后在您需要与服务器通信时询问存储桶中的内容。只要图标有一些独特的属性（例如id）来识别它们，那么您就可以根据需要动态构建模型。像这样的东西可以用来序列化你的桶：

http://jsfiddle.net/ambiguous/3ufhn/

只要事情保持简单，它就会很好地工作。如果事情变得更复杂，那么明确的 MVC 设置会让事情变得更容易，John K 的.data 方法会派上用场；您还可以使用带有隐藏输入的<form> 来跟踪您的状态。

【讨论】：

事后看来，这似乎是一种更好的方法（至少在我目前的情况下）。就我所拥有的而言，将名称存储在 ids 中肯定会减少混乱和更简单的代码。

@NRaf：这真的取决于事情的复杂程度。如果您有一个显式模型，那么您需要稍微扭转一下，以便模型在视图中表达（即视图由模型的数据驱动），而不是视图隐含的模型。建立正确的 MVC 关系有一些开销，但它可能是值得的。如果您开始遇到同步问题，那么是时候采用更正式的方法了，但在简单的情况下，正式的 MVC 可能会过度设计。