При использовании Backbone + Stickit нужно ли объектам модели представления расширять Backbone.Model?

Проще говоря, различные компоненты в шаблоне MVVM

  • Model: это представляет данные, отправленные сервером и отправленные обратно на сервер. это не содержит состояния, связанного с отображением пользовательского интерфейса
  • ViewModel: это построено из одной или моделей. содержит состояние, предназначенное для манипулирования пользовательским интерфейсом (кнопка включена или отключена). вся логика, предназначенная для манипулирования пользовательским интерфейсом, хранится здесь. этот уровень не зависит от какой-либо инфраструктуры пользовательского интерфейса (без вызовов jQuery)
  • View Это тесно связано с каркасом UI / базовыми элементами управления UI. Один вид соблюдает одну и только одну модель вида. Модель вида может наблюдаться одним или несколькими видами. Представление отвечает за две связи с моделью представления.
  • presenter/coordinator Хотя это и не является частью традиционной реализации, в ее отсутствие модель представления заканчивается слишком большой ответственностью. Этот парень помогает координировать выполнение вызовов ajax (get/post), прослушивание событий в глобальном агрегаторе событий и т. Д.

Автономная магистраль не имеет понятия моделей представлений и привязки данных. В этом случае данные, возвращаемые сервером, могут быть смоделированы как Backbone.Model объекты. Привязки выполняются вручную, и POJO можно использовать для синхронизации модели представления.

Если я хочу использовать Stickit для привязки данных, похоже, что модель представления должна быть экземпляром Backbone.Model, Главным образом потому, что привязки работают в контексте Backbone.View и Backbone.View ожидает Backbone.Model объект должен присутствовать как свойство представления. Кроме того, Backbone.Model вызывает события изменения, а что нет. Я предполагаю, что будет трудно наблюдать за POJO. Опять же, это мое понимание от чтения документов Stickit. Пожалуйста, поправьте меня, если я ошибаюсь.

Backbone.Model есть другие методы, которые не имеют смысла с точки зрения модели представления, такие как save, fetch и т.д. я читал в другой библиотеке mvvm, Knockback, Это может преобразовать Backbone.Model в Knockout.js посмотреть модель. Вместо прохождения в полноценный Backbone.Model, он также может принимать любые POJO, которые имеют методы get/set и генерируют события изменения, когда свойства изменяются.

Имеет ли Stickit аналогичный контракт, в котором я могу передать POJO, который имеет методы get/set и вызывает события change? Какое рекомендуемое использование?

1 ответ

В исходном коде Backbone.Stickit нет ничего, что требовало бы, чтобы модель действительно была экземпляром Backbone.Model. Таким образом, кажется, что Stickit просто нужен какой-то объект, который поддерживает контракт, предоставленный Backbone.Model - различные приложения set(), get() и on() - все, что, я думаю, вам нужно.

Взгляните на тестовый набор Стикита. Если вы написали свой собственный API модели, который прошел эти тесты (заменив Backbone.Model своей собственной реализацией в testScaffolding.js- и предположив, что тесты тщательные - тогда вы сможете использовать эту модель с Stickit.

РЕДАКТИРОВАТЬ: Я, возможно, не обратился непосредственно к вопросу. Stickit требует только того, чтобы вы использовали его в Backbone.View, и чтобы это представление имело modelили какой-либо другой объект, указанный optionalModel параметр, который вы можете передать stickit() функция, которая соответствует контракту, предоставленному Backbone.Model.

Другие вопросы по тегам