在了解Backbone.js的MVC的内部结构的依赖 [英] Understanding the internal structural dependencies of MVC in Backbone.js

问题描述

我有点糊涂了w.r.t.设计结构的依赖时，你的MVC - 所以我们有一个模型，收集和查看（我没有使用控制器迄今为止，但问题适用于它太）。现在的谁拥有谁的OO术语讲一个参考。因此，收集的车型，所以我们可以把它看成是一个一对多的依赖从收集到的模型的列表。在一些例子codeS的我有时会看到在模式的对象有一定的参考，以一个视图，视图模型的参考。有时，在视图中的集合。

I'm a bit confused w.r.t. the structural dependencies when designing your MVC - so we have a Model, Collection and View (I'm not using controllers as yet, but the question applies to it too). Now who has a reference of whom to speak in OO terms. So the collection is a list of models so we can think of it as a one to many dependency from collection to model. In some of the example codes I sometimes see some reference to a view in the 'model' object and the reference of the model in the view. Sometimes a collection in the view.

在模型中，有时会看到一个 this.view 和我看到类似的看法 this.model.view 或 this.model ，从而混淆澄清：）

In the model I sometimes see a this.view and in the view I see something like this.model.view or a this.model and thus the confusion to clarify :)

那么，什么是正确的设置相关性（如果有的话，就是一个正确的方式），或者每个人都可以依赖于每个人（不认为这是正确的），即，谁最好应依赖谁在对象的骨干MVC设计？这只是一个有点混乱知道应该如何当我看到这样的例子不同，他们在结构有关 - 从一个小白点:)作为一个小白什么是正确的方式开始构建我的依赖关系 - 一旦我了学习曲线我可能会找出自己，但启动，应该怎么做呢？一个UML图一样会是一个额外的好处;）

So what is the 'right' set of dependencies (if there is "a" right way that is) or can everyone be dependent on everyone (don't think that is correct) I.e., who should ideally be dependent on whom in Backbone's MVC design of objects? It's just a bit confusing to know how should they be structurally related when I see such disparate examples - from a noob point of view :) As a noob what is the 'right' way to start structuring my dependencies - once I'm up the learning curve I'd probably figure it out myself, but to start with, how should one go about it? A UML-like diagram would be an added bonus ;)

另一个问题：
有时我看到在同一块code的两种观点：例如：著名的todo.js <一个href=\"http://documentcloud.github.com/backbone/docs/todos.html\">http://documentcloud.github.com/backbone/docs/todos.html

现在，虽然我明白的多个视图的需要，是什么困惑的是如何有不同？我的意思是一个厄尔尼诺和标签名和怎样的看法不同的表现，如果他们中的任何一个不存在的区别？我的意思是上面一个视图中使用'标签名'和其他'厄尔尼诺'的链接，我真的不知道他们是如何相互关联（如果有的话）。

Now although I understand the need of multiple views, what is confusing is how are they different? I mean what's the difference between an 'el' and 'tagName' and how does the view behave differently if either one of them is absent? I mean in the link above one view uses 'tagName' and the other 'el' and I'm not really sure how they correlate (if at all).

我已经通过文件集中了，但正如我所说，我还在学习，所以我可能只是不明白它的某些部分显然即使在地方的所有资源，可能需要一些人工干预：）

I've gone through the documentation intensively, but as I said I'm still learning so I may just not understand parts of it clearly even with all the resources in place and may need some human intervention :)

推荐答案

由于Backbone.js的不是一个框架，因此，没有单一的正确的方式做任何事情。不过，也有在执行一些提示，帮助你的想法。此外，还有一些常规时间考验code的组织，你可以申请的做法。但我会先解释的意见。

Since Backbone.js is not a framework as such, there's no single "right" way to do anything. However, there are some hints in the implementation that help you to get the idea. Also, there are some general time-tested code organization practices which you can apply. But I'll explain the views first.

在骨干视图是依赖于特定的DOM元素（这是报属性是什么）。

Views in Backbone are tied to particular DOM elements (that's what the el property is for).

如果，当视图初始化时，它有一个报属性，那么Backbone.js的使之成为新的视图实例的属性。否则，它会查找标签名， ID 和的className 属性，创建相应的DOM对象，而新的视图实例的埃尔属性反正它分配给。 （它在源）。如果还有的甚至没有标签名，那么＆LT; D​​IV＆GT; 元素默认情况下创建

If, when the view is initialized, it has an el attribute, then Backbone.js makes it a property of the new view instance. Otherwise it looks for tagName, id, and className attributes, creates the corresponding DOM object, and assigns it to the el property of the new view instance anyway. (It's explained in the source.) If there's even no tagName, then <div> element is created by default.

所以，你可以猜测为什么 TodoView 和 APPVIEW 使用不同的方法。在 #todoapp <​​/ code>元素最初存在于HTML页面上，所以 APPVIEW 可以只使用它。但是，创建一个待办事项视图时，有它目前还没有DOM元素;在类使开发者标签名中定义的骨干自动创建一个列表项。 （它不会是很难受的手在初始化（）的方法做，但骨干网做它为您节省了一些时间。）

So, you can guess why TodoView and AppView use different approaches. The #todoapp element exists initially on the page in the HTML, so AppView can just use it. But when a view for a todo item is created, there's no DOM element for it yet; so the developer has tagName defined on the class for Backbone to create a list item automatically. (It wouldn't be hard to do by hand in the initialize() method, but Backbone saves some time by doing it for you.)

通常一个观点分为两类：对意见模型实例，并享有对集合。骨干网没有的力的，但它的建议的，它可能是你想要什么：如果你实例化视图集或模式选项，他们成为新创建的视图实例的属性，所以您可以通过 view.collection 或 view.model 。 （如果您例如，实例化富选项来看，它会被放入 view.options.foo 。）

Usually a view falls into one of two categories: views for model instances, and views for collections. Backbone doesn't force it, but it suggests that it's probably what you want: if you instantiate the view with collection or model options, they become properties of the newly created view instance, so you can access them via view.collection or view.model. (If you, for example, instantiate the view with foo option, it will be put into view.options.foo.)

这只是我的看法。

• 依赖较少为好。

• Less dependency is better.

继MVC模式有很大的优势。

Following the MVC pattern has a lot of advantages.

需要注意的是Backbone.js的术语不符合MVC的经典之一。这是正常的，MVC！=一组类，它的定义有所不同了一下。它更多的'，你应该在你的脑海里的理想（从的什么是MVC，什么是它的优势是什么？）。

Note that Backbone.js terminology does not match MVC's classical one. That's normal, MVC != a set of classes, and its definitions vary a bit. It's more of ‘an ideal that you should have in the back of your mind’ (quoted from What is MVC and what are the advantages of it?).

MVC        | Backbone.js                 | What it does
Controller | View (mostly)               | Handles user interaction
View       | template rendered by a view | Displays the data
Model      | Model & Collection          | Represents the data, handles data access

• 模型层通常不应依赖于任何东西。在MVC，型号是您访问您的数据。这已无关，也就是说，这个数据的presentation。

  • The model layer should not normally depend on anything. In MVC, model is where you access your data. That has nothing to do with, say, the presentation of this data.

    在骨干网中，模型可以对一些收集的一部分，但是这并不是一个严重依赖（据我所知，它只是帮助自动找出对应这个模型API端点的网址）。

    In Backbone, a model can be a part of some collection, but that's not a heavy dependency (AFAIK, it just helps to automatically figure out URLs of API endpoints corresponding to this model.)

    在骨干网，集合可能有相应的模型类分配，而且这也是没有必要的。

    In Backbone, a collection may have a corresponding model class assigned, but that's also not necessary.

    在骨干网中，路由器通常取决于更高级别的意见（如对意见整个页面或页面的部分），以使它们以响应应用程序状态的变化。这些观点，又依赖于一些低级别的观点一样，部件/页节。这些视图可以依赖于收藏等，甚至更低水平的观点。这些，反过来，取决于特定的模型实例。

    In Backbone, a router usually depends on higher-level views (like views for entire pages or sections of the page), to render them in response to a change in application's state. These views, in turn, depend on some lower-level views, like widgets / page sections. These views can depend on collections and other, even more low-level views. These, in turn, can depend on particular model instances.

    作为一个例子（箭头表示依赖关系类型）：

    As an example (arrows denote "depends on" type of relationship):

    
               +-------------+              +---------------+   +------------+
    State      |MainRouter   |       Data:  |ItemCollection |   |ItemModel   |
    Control:   |-------------|              |---------------|   |------------|
               |             |              |/api/items     +-->|/api/items/*|
               |             |              |               |   |            |
               |             |              |               |   |            |
               +---+-+-------+              +---------------+   +------------+
                   | +----------------+                  ^              ^
                   v                  v                  |              |
               +-------------+   +-------------+         |              |
    Page-level |AboutView    |   |AppView      |         |              |
    views:     |-------------|   |-------------|         |              |
               | section     |   | section     |         |              |
               | role="main" |   | role="main" |         |              |
               +--+-+--------+   +--+-+-+------+         |              |
                  | +---------------|-|-|----+           |              |
                  |      +----------+ | +----|---------+ |              |
                  v      v            v      v         v |              |
               +--------------+   +--------------+   +---+-----------+  |
    Widget     |SidebarView   |   |HeaderView    |   |ItemListView   |  |
    views:     |--------------|   |--------------|   |---------------|  |
               | aside        |   | header       |   | ul            |  |
               |              |   |              |   |               |  |
               |              |   |              |   |               |  |
               +--------------+   +--------------+   +-----------+---+  |
                                                                 |      |
                                                                 v      |
                                                               +--------+---+
                                                               |ItemAsLiView|
                                                               |------------|
                                                               | li         |
                                                               |            |
                                                               +------------+
    

    请注意，你可以有多个路由器设置，在这种情况下，事情可能看起来有点不同。

    Note that you can have multiple routers set up, in which case things may look a bit differently.

    在托多斯例如，开发人员决定待办事项模型实例应该取决于相应TodoView实例。当 TodoView 被实例化，它创建于相应的模型实例的属性视图，并将自己指定给它。因此，它可以通过 some_todo_model.view 进行访问。但是，应该指出的是， model.view ，在一次待办事项模型仅用于清（）方法，当模型被清除以删除视图实例。

    In the Todos example, the developer decided that Todo model instances should depend on corresponding TodoView instances. When TodoView is instantiated, it creates on the corresponding model instance a property view and assigns itself to it. So that it could be accessed by some_todo_model.view. However, it should be noted that model.view is only used once—in Todo model's clear() method, to remove the view instance when the model is cleared.

    我觉得是的特别的依赖是没有必要的。然而，对于这样一个小应用程序，它可能会好起来的。

    I think that particular dependency isn't necessary. However, for such a small application, it may be okay.

    我找不到在视图访问 this.model.view 中的任何例子，所以我不能对此发表评论。

    I couldn't find any example of accessing this.model.view in the view, so I can't comment on this.

    
    
    • 将朱利安Guimont 答案的-almost所有的人都约Backbone.js的，我认为这是一个伟大的信息来源
    
    
    • Answers by Julien Guimont—almost all of them are about Backbone.js, I think it's a great source of information.

    这篇关于在了解Backbone.js的MVC的内部结构的依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！