【问题标题】:Backbone structure骨干结构
【发布时间】:2013-01-28 12:50:14
【问题描述】:

我是主干新手,但看过几个关于它的教程截屏视频,包括有和没有 requirejs。

我的问题涉及设置结构(如果使用需要,则包括文件结构和/或变量/对象结构)。

我看过的大部分教程,似乎更喜欢 App.Models、App.Collections 和 App.Views 的方法,而且里面的每一项都有模块的名称:即,

App.Models.todo = Backbone.Model.extend({...});
App.Collections.todos = Backbone.Collection.extend({...});
App.Views.todo = Backbone.View.extend({...});

经过一番研究,试图找到与我想使用的风格相同的人,我终于找到了:File structure for a web app using requirejs and backbone。他们似乎更喜欢 App.[Module Name] 方法:即,

App.Todo.Model = Backbone.Model.extend({...});
App.Todo.Collection = Backbone.Collection.extend({...});
App.Todo.Views = Backbone.View.extend({...});

我个人更喜欢 App.[Module Name] 结构而不是拆分我的模块,但我想知道拥有不同结构的好处(如果有的话)。

您使用哪种结构,它对您过去可能见过或使用的不同结构有何帮助?

【问题讨论】:

  • 这主要是个人喜好问题。我认为你只会得到一堆意见。
  • 这是工作流程的问题。您可以按组件类型 (App.Models.*)(即一名开发人员主要处理视图,其他人处理模型)进行根植,或者您针对上下文进行优化(App.Accounts.Model)以保持事物(业务)的逻辑分组。但就像@muistooshort 所说,这个问题无法客观回答,因此并不适合StackOverflow 格式。
  • 我同意大多数答案都是意见。我只是想看看是否对另一个有任何实际好处,是否有一些我没有见过的“最佳实践”,或者它是否是 100% 的意见(“无论你喜欢什么”) .
  • @PaulWitschger,没有深入到理论上的文化相对主义,我想说这只是意见。显然有更好和更坏的方法。例如,我不建议使用 GUID 命名所有文件,但在您建议的两种方式之间,这取决于您。我做App.{Module}.*,FWIW。
  • 这里有一个资源可以作为起点:backbonetutorials.com/organizing-backbone-using-modules

标签: backbone.js


【解决方案1】:

【讨论】:

    【解决方案2】:

    如果您使用 requireJS,您不需要/不想将模型/视图附加到附加到窗口的全局命名空间对象(没有 App.Views、App.Models)。使用 requireJS 或其他 AMD 模块加载器的好处之一是您可以避免使用全局变量。

    您可以这样定义模型:

    define(['underscore', 'backbone'], 
        function(_, Backbone) {
        var MyModel = Backbone.Model.extend({});
    
        return MyModel;
    });
    

    然后你定义一个视图:

    define(['underscore', 'backbone', 'tpl!templates/someTemplate.html'],
      function(_, Backbone, template) {
      var MyView = Backbone.View.extend({});
    
      return MyView;
    });
    

    现在您有了一个模型和一个没有全局变量的视图。然后,如果其他一些模块需要创建其中之一(可能是您的 App 模块),您将其添加到 define() 数组中即可。

    【讨论】:

    • 如果您阅读了我的问题的第二段,如果使用 require(而不仅仅是命名空间),我也会参考文件结构。通过您示例中模板的位置,我假设您使用模型/、视图/、集合/和模板/?不是模块/模型、模块/集合等?如果是这样,你走这条路的原因是什么?与模块/路线相比有什么好处?
    • 就像其他人所说的那样,它是非常主观的,我对这部分没有强烈的意见 :) 模块/模型和模块/视图可能存在的问题是,您可能有一天会决定使用一个“模块”与另一个“模块”的特定模型。但是,我认为这里的“模块”一词有两点混淆。使用 requireJS,“模块”是您定义和返回的任何内容,通常是对象(模型/视图/等)的构造函数,就像我帖子中的代码一样。还有另一个概念是“模块”是这些东西的集合(模型 + 视图 + ...)。
    猜你喜欢
    • 2012-05-04
    • 1970-01-01
    • 2015-03-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多