Comprendre les dépendances structurelles internes de MVC dans Backbone.js

Depuis Épine Dorsale.js n'est pas un framework en tant que tel, il n'y a pas de "bonne" façon de faire quoi que ce soit. Cependant, il y a quelques conseils dans la mise en œuvre qui vous aident à avoir l'idée. En outre, il existe des pratiques générales d'organisation de code éprouvées par le temps que vous pouvez appliquer. Mais je vais d'abord expliquer les points de vue.

Vues

Dans Backbone sont liées à des éléments DOM particuliers(c'est à quoi sert la propriété el).

Si, lorsque la vue est initialisée, elle a un el attribut, puis Backbone.js en fait une propriété de la nouvelle instance de vue. Sinon, il cherche tagName, id, et className attributs, crée l'objet DOM correspondant, et l'affecte à la propriété el de la nouvelle instance de vue de toute façon. (C'est expliqué dans la source.) S'il n'y a même pas tagName, alors l'élément <div> est créé par défaut.

Ainsi, vous pouvez deviner pourquoi TodoView et AppView utiliser des approches différentes. L'élément #todoapp existe initialement sur la page dans le HTML, donc AppView peut juste l'utiliser. Mais quand une vue pour un élément todo est créée, il n'y a pas encore D'élément DOM pour cela; donc le développeur a tagName défini sur la classe pour Backbone pour créer automatiquement un élément de liste. (Ce ne serait pas difficile à faire à la main dans la méthode initialize(), mais Backbone économise du temps en le faisant pour vous.)

Généralement, une vue se classe dans l'une des deux catégories suivantes: vues pour les instances de modèle et vues pour les collections. Épine dorsale n'est pas force, mais il suggère, ce qui c'est probablement ce que vous voulez: si vous instanciez la vue avec les options collection ou model, elles deviennent des propriétés de l'instance de vue nouvellement créée, vous pouvez donc y accéder via view.collection ou view.model. (Si vous, par exemple, instanciez la vue avec l'option foo, elle sera placée dans view.options.foo.)

Dépendances

Bonnes pratiques

Ceci est juste mon opinion.

• Moins de dépendance, c'est mieux.

• Suivre le modèle MVC a beaucoup de avantage.

  Notez cette colonne vertébrale.la terminologie js ne correspond pas à celle classique de MVC. C'est normal, MVC != un ensemble de classes, et ses définitions varient un peu. C'est plus "un idéal que vous devriez avoir à l'arrière de votre esprit" (Cité de Qu'est-ce que MVC et quels en sont les avantages?).

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

• La couche de modèle ne devrait normalement dépendre de rien. Dans MVC, le modèle est l'endroit où vous accédez à vos données. Cela n'a rien à voir avec, disons, le la présentation de ces données.

  Dans Backbone, un modèle peut faire partie d'une collection, mais ce n'est pas une dépendance lourde (AFAIK, cela aide simplement à comprendre automatiquement les URL des points de terminaison D'API correspondant à ce modèle.)

• Dans Backbone, une collection peut avoir une classe de modèle correspondante assignée, mais ce n'est pas non plus nécessaire.

• Dans Backbone, un routeur dépend généralement des vues de niveau supérieur (comme les vues pour des pages entières ou des sections de la page), pour les rendre en réponse à un changement dans l'application de l'état. Ces vues, à leur tour, dépendent de certaines vues de niveau inférieur, comme les widgets / sections de page. Ces vues peuvent dépendre de collections et d'autres vues, encore plus basses. Ceux-ci, à leur tour, peuvent dépendre d'instances de modèle particulières.

À titre d'exemple (les flèches indiquent "dépend" du type de relation):

           +-------------+              +---------------+   +------------+
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         |
                                                           |            |
                                                           +------------+

Notez que vous pouvez configurer plusieurs routeurs, auquel cas les choses peuvent sembler un peu différemment.

Todos.js

Dans L'exemple Todos, le développeur a décidé que les instances de modèle Todo devraient dépendre des instances TodoView correspondantes. Lorsque TodoView est instancié, il crée sur l'instance de modèle correspondante une propriété view et s'y assigne. De sorte qu'il pourrait être accessible par some_todo_model.view. Cependant, il convient de noter que model.view n'est utilisé qu'une seule fois dans la méthode clear() du modèle Todo, pour supprimer l'instance de vue lorsque le modèle est effacé.

Je crois cette dépendance particulière n'est pas nécessaire. Cependant, pour une si petite application, ça peut aller.

Je n'ai trouvé aucun exemple d'accès à this.model.view dans la vue, donc je ne peux pas commenter cela.

Voir aussi

• les réponses de Julien Guimont -presque toutes concernent L'épine dorsale.js, je pense que c'est une excellente source d'information.