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

Question

Je suis un peu confus w.r.t. les dépendances structurelles lors de la conception de votre MVC - nous avons donc un Modèle, de la Collecte et de la Vue (je ne suis pas à l'aide de contrôleurs, mais la question s'applique à lui aussi). Maintenant, qui a une référence qui parler dans OO termes. Si la collection est une liste de modèles, de sorte que nous pouvons penser que c'est un "un à plusieurs" dépendance à partir de la collection de modèle. Dans certains de l'exemple des codes que je vois parfois certains de référence à un affichage dans le "modèle" de l'objet et la référence du modèle dans la vue. Parfois, une collection dans la vue.

Dans le modèle que je vois parfois un this.view et dans la vue, je vois quelque chose comme this.model.view ou this.model et donc de la confusion pour clarifier les choses :)

Alors, quelle est la "bonne" ensemble de dépendances (si il y a "une" bonne manière) ou peut-être tout le monde dépend de tout le monde (ne pense pas que c'est correct) I. e., qui devrait idéalement être dépend de qui de la colonne vertébrale MVC du design d'objets? C'est juste un peu déroutant de savoir comment doivent-ils être structurellement lié quand je vois de tels exemples disparates - à partir d'un noob point de vue :) Comme un noob qu'est-ce que la "bonne" façon de commencer la structuration de mes dépendances - une fois que je suis la courbe d'apprentissage je serais probablement comprendre moi-même, mais pour commencer, comment doit-on procéder? Un langage de modélisation UML, comme le diagramme serait un bonus supplémentaire ;)

Une autre question: Parfois, je vois deux points de vue dans le même morceau de code: exemple: le célèbre todo.js http://documentcloud.github.com/backbone/docs/todos.html

Maintenant, même si je comprends la nécessité de points de vue multiples, ce qui est déroutant, c'est comment sont-ils différents? Je veux dire quelle est la différence entre un " el " et "tagName" et comment le point de vue se comportent différemment si l'un d'eux est absent? Je veux dire que dans le lien ci-dessus une vue utilise des "tagName" et l'autre " el " et je ne suis pas vraiment sûr de savoir comment ils sont reliés l'un (si).

Je suis passé par la documentation de manière intensive, mais comme je l'ai dit, je suis encore en apprentissage donc je peut tout simplement pas comprendre parties clairement, même avec toutes les ressources en place et peuvent avoir besoin d'une intervention humaine :)

Answer 1

Depuis Backbone.js n'est pas un cadre en tant que tel, il n'y a pas une seule "bonne" façon de faire n'importe quoi. Cependant, il y a des nuances dans la mise en œuvre que vous aider à avoir l'idée. Aussi, il y a quelques temps-testé le code de l'organisation des pratiques que vous pouvez appliquer. Mais je vais vous expliquer le point de vue d'abord.

Vues

Vues de la colonne vertébrale sont liés à certains éléments du DOM (c'est ce que l' el de la propriété est pour).

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

Ainsi, vous pouvez deviner pourquoi TodoView et AppView utiliser des approches différentes. L' #todoapp élément existe d'abord sur la page en HTML, AppView pouvez simplement l'utiliser. Mais quand une vue pour une todo élément est créé, il n'y a aucun élément du DOM pour encore; de sorte que le développeur a tagName définie sur la classe de base pour créer un élément de liste automatiquement. (Il ne serait pas difficile de le faire à la main dans l' initialize() méthode, mais épine Dorsale permet de gagner du temps en le faisant pour vous.)

Généralement un point de vue relève de l'une des deux catégories: les vues pour les instances de modèle, et de vues pour les collections. Épine dorsale n'a pas la force , mais il suggère que c'est probablement ce que vous voulez: si vous instanciez le point de vue d' collection ou model options, ils deviennent des propriétés de l'affichage nouvellement créé instance, de sorte que vous pouvez accéder via view.collection ou view.model. (Si vous avez, par exemple, créer une instance de la vue avec l' foo option, il sera mis en view.options.foo.)

Dépendances

Les bonnes pratiques

C'est juste mon avis.

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

• Suivant le modèle MVC a beaucoup d'avantages.

  Notez que Backbone.js la terminologie ne correspond pas à la MVC du classique. C'est normal, MVC != un ensemble de classes, et ses définitions varient un peu. C'est plus de l'idéal que vous devriez avoir dans le dos de votre esprit " (cité d'après Ce qui est MVC et quels sont les avantages de celui-ci?).

MVC | Backbone.js Ce qu'il ne
Contrôleur | Vue (pour la plupart) | Poignées interaction de l'utilisateur
Afficher | modèle rendu par vue | Affiche les données
Modèle | Model & de Collection | Représente les données, gère les accès aux données

• Le modèle de la couche ne doit pas normalement dépend de rien. Dans MVC, le modèle est l'endroit où vous accéder à vos données. Qui n'a rien à voir avec, par exemple, la présentation de ces données.

  De la colonne vertébrale, un modèle peut être une partie d'un ensemble, mais ce n'est pas une dépendance forte (autant que je sache, il aide à automatiquement comprendre Url de l'API de points de terminaison correspondant à ce modèle.)

• Dans la colonne vertébrale, une collection peut avoir un modèle correspondant de la classe assignée, mais c'est pas non plus nécessaire.

• De la colonne vertébrale, un routeur dépend généralement de niveau supérieur vues (comme les points de vue pour l'ensemble des pages ou des sections de la page), pour les rendre en réponse à un changement dans l'application de l'état. Ces points de vue, à son tour, dépend de certains de niveau inférieur vues, comme les widgets / sections de la page. Ces points de vue peuvent compter sur les collections et les autres, même à un niveau plus bas points de vue. Ces derniers, à leur tour, dépendent notamment d'instances de modèle.

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

 +-------------+ +---------------+ +------------+
Etat |MainRouter | Données: |ItemCollection | |ItemModel |
Contrôle: |-------------| |---------------| |------------|
 | | |/api/articles +-->|/api/articles/*|
 | | | | | |
 | | | | | |
 +---+-+-------+ +---------------+ +------------+
 | +----------------+ ^ ^
 v v | |
 +-------------+ +-------------+ | |
Au niveau de la Page |AboutView | |AppView | | |
vues: |-------------| |-------------| | |
 | article | | article | | |
 | role="main" | | role="main" | | |
 +--+-+--------+ +--+-+-+------+ | |
 | +---------------|-|-|----+ | |
 | +----------+ | +----|---------+ | |
 v v v v v | |
 +--------------+ +--------------+ +---+-----------+ |
Widget |SidebarView | |HeaderView | |ItemListView | |
vues: |--------------| |--------------| |---------------| |
 | de côté | | en-tête | | ul | |
 | | | | | | |
 | | | | | | |
 +--------------+ +--------------+ +-----------+---+ |
 | |
 v |
+--------+---+
|ItemAsLiView|
|------------|
 | li |
 | |
+------------+

Notez que vous pouvez avoir plusieurs routeurs mis en place, auquel cas les choses un peu différemment.

todos.js

Dans le Todos exemple, le développeur a décidé qu' Todo d'instances de modèle devrait dépendre de l'correspondant TodoView instances. Lors de l' TodoView est instancié, il crée sur le modèle de l'exemple d'une propriété view et s'attribue à elle. De sorte qu'il peut être consulté en some_todo_model.view. Toutefois, il convient de noter que model.view est utilisée une fois seulement-en Todo modèle clear() méthode, pour supprimer le point de vue de l'instance lorsque le modèle est désactivée.

Je pense que la dépendance n'est pas nécessaire. Cependant, pour une petite application, il est peut-être bien.

Je ne pouvais pas trouver un exemple d'accéder this.model.view dans la vue, donc je ne peux pas commenter sur ce point.

Voir aussi

• Réponses par Julien Guimont-la quasi-totalité d'entre eux sont sur le Backbone.js je pense que c'est une excellente source d'information.