1

我意识到对此有很多解决方案，但我想知道社区的意见是什么。

我有一系列的模型和收藏品。每个模型都有许多视图，如详细信息、编辑、打印、搁置、帮助等。集合具有通常具有相同名称的视图（即：搁置、帮助等）。

我的一个要求是我需要在模块中构建我的代码。如果未加载模块，则应用程序不应跟踪模块的功能。例如，如果用户没有查看、编辑等其他用户的权限，则可能会发生这种情况。所以“用户”模块甚至不会被加载。

所以...

我认为存储模型视图定义的好地方可能是模型的构造函数和集合构造函数中的集合。例如：

var User = (function(){ // module definition

    // model definition
    var Model = Backbone.Model.extend({
        initialize: function() {
            // ...
        }
    },{
        Views: {
            Details: Backbone.View.extend({
                // ...
            }),
            Aside: Backbone.View.extend({
                // ...
            }),
            Help: Backbone.View.extend({
                // ...
            })
        }
    });

    // collection definition
    var Collection = Backbone.Collection.extend({
        model: Model,
        initialize: function() {
            // ...
        }
    },{
        Views: {
            Aside: Backbone.View.extend({
                // ...
            }),
            Help: Backbone.View.extend({
                // ...
            })
        }
    });

    // add more code here

    return { // make model and collection public
        Model: Model,
        Collection: Collection
    };

})(); // end module definition

我意识到我可以将我的观点存在于其他地方，但这种方法是否有任何我可能不知道的相当大的缺点？也许是内存泄漏或不太明显的东西？

谢谢！

4

2 回答 2

0

看看require.js。有了它，您应该能够添加处理模块加载的逻辑。一般来说，您仍然应该看看它，它非常适合组织主干应用程序，尤其是使用text plugin。

于 2012-12-04T22:27:04.667 回答
0

我认为最好不要将视图作为“类方法”添加到模型和集合中。由于JavaScript 原型继承的性质，您实际上并没有向模型类型的构造函数添加属性，而是添加类方法。至于这是否会导致您出现内存泄漏等问题，我不能说。

相反，我会说，除非你有一个未列出的令人信服的理由来使用这种结构，否则你最好只对简单对象的视图进行分组。

如果目标是模块化您的代码，我会利用诸如require.js或Marionette 模块之类的东西，或者只是将“相关”代码分组到 IIFE 中。

如果您有兴趣了解更多关于传递到方法中的具体发生了什么classPropertiesBackbone.Model.extend，那么我建议您直接查看带注释的源代码。

于 2012-12-05T02:00:25.290 回答