Understanding the internal structural dependencies of MVC in Backbone.js

Question

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

Answer 1

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.

Views

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

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.

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.)

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.)

Dependencies

Good practices

This is just my opinion.

• Less dependency is better.

• Following the MVC pattern has a lot of advantages.

  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

• 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.

  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.

todos.js

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.

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

See also

• Answers by Julien Guimont—almost all of them are about Backbone.js, I think it's a great source of information.