【问题标题】:Issue structuring JavaScript (separation of view and model logic)问题结构化 JavaScript(视图和模型逻辑分离)
【发布时间】:2011-04-29 05:45:38
【问题描述】:

我正在为一个网站(目前,我正在制作一个原型)开发一个大量 Javascript 的作品(使用 jQuery)。

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

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

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

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

有什么想法吗?

【问题讨论】:

    标签: javascript jquery view model


    【解决方案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 可能会过度设计。
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-09-17
        • 2018-07-09
        • 1970-01-01
        • 2013-12-15
        • 2016-03-02
        相关资源
        最近更新 更多