Backbone.js - Où stocker les informations d'état?

Question

Je suis nouveau sur Backbone.jset je suis à essayer de comprendre où les variables d'état doit vivre. Mon cas d'utilisation:

J'ai une application qui fournit une interface de lecture d'un livre (je sais, l'exemple classique, non?). Mes modèles sont des Book et Page avec les classes de collection pour chaque. La structure de l'application ressemble à peu près comme ceci (pardonnez l'ASCII visio):

+------------+
| Controller |
+------------+
    |      Views                 Models
    | +--------------+      +----------------+
    |-|  IndexView   |------| BookCollection |
    | +--------------+      +----------------+
    |                               |
    | +--------------+      +----------------+
    +-|   BookView   |------|     Book       |
      +--------------+      +----------------+
       |                            |
       | +--------------+           |
       |-|  TitleView   |-+         |
       | +--------------+ | +----------------+
       |                  +-|     Page       |
       | +--------------+ | +----------------+ 
       +-|   PageView   |-+
         +--------------+ 

Qui est, l' Controller instancie et les coordonnées de deux points de vue, IndexView et BookView, soutenu par les modèles. L' BookView instancie et coordonne un ensemble de sous-vues (il y a en fait plus que ce qui est illustré ici).

Les informations d'état comprend:

• le livre en cours de pointeur (ou id)
• la page en cours de pointeur (ou id)
• d'autres interfaces utilisateur les variables d'état, comme si les images sur la page sont visibles ou pas, si les autres widgets sont ouverts ou fermés, etc.

Ma question est, où les informations d'état de vivre? Les options possibles comprennent:

• Les modèles, ce qui pourrait être l'état de conscience. Cela fait un certain sens, car ils sont conçus pour stocker des données et des vues d'écouter les modifications de l'état, mais il ne semble pas que cela s'inscrit le but Backbone.js motif, et n'est pas toujours logique (par exemple, tourner l'image dans l' PageView devrait s'appliquer à toutes les pages, et pas seulement celui en cours)

• Un spécial singleton modèle destiné à contenir des informations d'état. Encore une fois, de sens, facile à écouter, à tous les points de vue pourrait se lier à elle - mais encore une fois, ce qui semble en dehors de la norme MVC.

• Les points de vue, qui sont responsables de l'INTERFACE utilisateur de l'état, mais cela nécessiterait des points de vue à être attentifs les uns aux autres pour obtenir de l'état de l'info, qui semble incorrect

• Le contrôleur, qui devrait acheminer l'application, entre les états - cela fait sens, mais il implique un peu étrange voyage aller-retour, par exemple, User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (plutôt que la simple User selects "Show Images" --> View event listener is called --> View updates)

Je suppose que d'une certaine façon c'est un générique MVC question, mais je vais avoir du mal à obtenir ma tête autour de lui. Quelle partie de l'application doit être responsable de la sauvegarde de l'état actuel?

Mise à JOUR: référence Pour l'avenir, j'ai utilisé un mondial singleton modèle de l'État pour résoudre ce problème. Le flux d'INTERFACE utilisateur qui va comme ceci:

1. Vue de l'INTERFACE utilisateur des gestionnaires, mais ne rien faire mise à jour de app.State
2. Mes routeurs aussi ne rien faire, mais la mise à jour app.State - ils sont essentiellement vues spécialisées d'affichage et de réagir aux changements de l'URL
3. Vues écouter, à des changements sur app.State et mise à jour en conséquence

Mon application est Open Source, vous pouvez voir le code sur Github. La question ici est le modèle de l'État, qui je l'ai étendu à traiter avec la (dé)sérialisation de l'état pour l'URL.

Answer 1

Ne limitez pas votre épine Dorsale des applications à l'épine Dorsale des constructions. Si vous trouvez que votre application a besoin de certaines fonctionnalités qui ne rentre pas bien dans un "Backbone" de constructions, de ne pas chausse-pied dans un juste pour l'amour de tout garder la colonne vertébrale.

J'ai trouvé ce squelette réutilisable pour être utile à cet égard. Il met en place des modules pour vous et vous offre un objet d'application qui s'étend de la colonne vertébrale.Des événements (comme dans le déjà-article lié). Cette application objet peut être utilisé pour stocker instancié modèles, vues et contrôleurs/routeurs, et sentez-vous libre pour ajouter vos propres non épine dorsale des modules de l'application de l'objet, de prendre soin des responsabilités qui ne rentrent pas parfaitement dans l'une de l'épine Dorsale des constructions.

Answer 2

Pourquoi ne pas créer un modèle d'état de stocker et de décrire l'état actuel? Je ne pense pas que c'est faux. Depuis l'état actuel comprend plus d'un modèle, je pense qu'il est raisonnable de créer un modèle d'état de stocker et de recevoir de l'état actuel.

Le contrôleur peut alors communiquer avec le modèle d'état pour obtenir l'état actuel. Les états de l'INTERFACE utilisateur doivent être stockés dans le modèle correspondant bien. Le modèle d'état sait de quel livre et de la page, puis le livre et la page modèles de garder une trace de leurs états de l'INTERFACE utilisateur.