我意识到有很多解决方案,但我想知道社区的意见是什么。
我有一系列的模特和系列。每个模型都有许多视图,如细节,编辑,打印,旁边,帮助等。集合的视图通常具有相同的名称(即:旁边,帮助等)。
我的一个要求是我需要在模块中构建代码。如果未加载模块,应用程序应该没有模块功能的跟踪。例如,如果用户没有查看,编辑等其他用户的权限,则可能发生这种情况。因此甚至不会加载“用户”模块。
因此...
我认为存储模型视图定义的好地方可能是模型的构造函数和集合构造函数中的集合。例如:
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
我意识到我可以在其他地方看到我的观点,但这种做法是否有任何我可能不知道的相当大的缺点?也许内存泄漏或不太明显的东西?
谢谢!
答案 0 :(得分:0)
看看require.js。有了它,您应该能够添加处理模块加载的逻辑。一般来说,你仍然应该看看它,非常适合组织骨干应用程序,尤其是text plugin。
答案 1 :(得分:0)
我认为最好不要将您的视图作为“类方法”添加到模型和集合中。由于 JavaScript的原型继承的性质,您实际上并没有为模型类型添加类方法,而是将属性添加到构造函数。至于这是否会导致内存泄漏等问题,我不能说。
我想说,除非你有一个未列出令人信服的理由使用这种结构,你最好只是将你的观点分组为简单的对象。
如果目标是模块化您的代码,我会利用require.js或Marionette modules之类的内容,或者只是在IIFE中对“相关”代码进行分组。
如果您有兴趣了解有关 classProperties
的具体内容的更多信息,请通过Backbone.Model.extend
方法,我建议您直接查看{{3 }}