Backbone.js - где хранить информацию о состоянии?

Я новичок в Backbone.js, и я пытаюсь выяснить , где должны существовать переменные состояния. Мой прецедент:

У меня есть приложение, которое предоставляет интерфейс чтения для книги (я знаю, классический пример, правильно?). Мои модели Book и Page с классами сбора для каждого. Структура приложения выглядит примерно так (простить ASCII visio):

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

То есть, Controller создает и сопоставляет два вида, IndexView и BookView, подкрепленные моделями. BookView создает и координирует набор подпунктов (на самом деле здесь больше, чем показано здесь).

Информация о состоянии включает:

текущая книга (указатель или идентификатор)
текущая страница (указатель или идентификатор)
другие переменные состояния пользовательского интерфейса, например, видны ли изображения на странице или нет, открыты или закрыты другие виджеты и т.д.

Мой вопрос в том, где должна находиться эта информация о состоянии? Возможные варианты:

модели, которые могут быть осведомлены о состоянии. Это имеет смысл, поскольку они предназначены для хранения данных, а представления могут прослушивать изменения состояния, но похоже, что это не соответствует намеченному шаблону Backbone.js и не всегда имеет смысл (например, включение изображения в PageView должен применяться ко всем страницам, а не только к текущему)
A специальная одноэлементная модель, предназначенная для хранения информации о состоянии. Опять же, имеет смысл, легко слушать, все взгляды могут привязываться к нему, но опять же это кажется вне стандартного MVC.
представления, ответственные за состояние пользовательского интерфейса, но это потребует, чтобы представления знали друг о друге, чтобы получить информацию о состоянии, которая кажется неправильной
Контроллер , который должен маршрутизировать приложение между состояниями - это имеет смысл, но это подразумевает слегка нечетное круговое движение, например. User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (а не просто User selects "Show Images" --> View event listener is called --> View updates)

Я предполагаю, что в некотором роде это общий вопрос MVC, но у меня проблемы с его головой. Какая часть приложения должна отвечать за сохранение текущего состояния?

UPDATE:. В будущем для этой проблемы я использовал глобальную модель состояния Singleton. Поток пользовательского интерфейса выглядит следующим образом:

Обработчики пользовательского интерфейса ничего не делают, кроме обновления app.State
Мои маршрутизаторы также ничего не делают, кроме обновления app.State - это по сути специализированные представления, отображающие и реагирующие на изменения URL.
Представления прослушивают изменения на app.State и соответственно обновляют

Мое приложение - Open Source - вы можете увидеть код на Github. Ниже приведена соответствующая статья State model, которую я расширил, чтобы обработать (де) сериализующее состояние для URL-адреса.

Ответ 1

Почему бы не создать модель состояния для хранения и описания текущего состояния? Я не думаю, что это неправильно. Поскольку текущее состояние включает более одной модели, я считаю разумным создать модель состояния для хранения и получения текущего состояния.

Затем контроллер может связаться с моделью состояния, чтобы получить текущее состояние. Однако состояния пользовательского интерфейса должны храниться в соответствующей модели. Модель состояния знает, какая книга и какая страница, а затем книги и модели страниц отслеживают их текущие состояния пользовательского интерфейса.

Ответ 2

Не ограничивайте свои базовые приложения конструкциями Backbone. Если вы обнаружите, что ваше приложение нуждается в некоторой функциональности, которая не очень хорошо вписывается в одну из конструкций Backbone, не переустанавливайте ее в одном только ради сохранения всего в Backbone.

Я нашел этот базовый шаблон, чтобы быть полезным в этом отношении. Он устанавливает модули для вас и предоставляет вам объект приложения, который расширяет Backbone.Events(как в ранее связанной статье). Этот объект приложения можно использовать для хранения экземпляров моделей, представлений и контроллеров/маршрутизаторов, и вы должны не стесняться добавлять свои собственные модули без привязки к объекту приложения, чтобы выполнять обязанности, которые не идеально вписываются в один из Конструкции магистрали.