2015-08-04 5 views
4

В позвоночнике я могу использовать свои модели по-разному.Backbone ViewModel vs (Data) Модель

Как я понимаю, для хранения данных (возможно, с веб-сервера RESTful) используется модель данных (Data), а ViewModel используется для хранения информации о конкретном виде (например, скрытые/отображаемые состояния).

Большая часть моих знаний от this Вопрос.

После прочтения this статью, в которой автор говорит:

визуализации пользовательского интерфейса при изменении данных, а не взаимодействия пользователя

и

Течение: взаимодействие пользователя -> данные change -> view render.

Например, если мы пишем кнопку воспроизведения/паузы переключатель в аудиоплеер, поток будет:

  • сЗпп пользователя «играть»
  • модели (данные) изменения состояния в «играть»
  • Представление отображает в «играть» режим

После этого шаблон гарантирует, что изменения состояния запускается из других источников (например, ускоренная перемотка вперед, новый список воспроизведения, ошибка сети, электронная tc.) переключит нашу кнопку, чтобы сделать правильную вещь. Другими словами, у нас есть один источник правды: всякий раз, когда наша модель меняется, мы знаем, что мы должны отобразить нашу кнопку.

var PlayPauseButton = Backbone.View.extend({ 
    tagName: 'li', 
    className: 'icon', 
    initialize: function(){ 
    this.model.on('change:status', this.render, this); 
    }, 
    render: function(){ 
    this.$el.removeClass('icon-play').removeClass('icon-pause'); 
    this.$el.addClass('icon-' + (this.isPlaying() ? 'pause' : 'play')); 
    }, 
    events: { 
    'click': function(){ 
     this.model.set('status', this.isPlaying() ? 'paused' : 'playing'); 
    } 
    }, 
    isPlaying: function(){ 
    return this.model.get('status') === 'playing'; 
    } 
}); 

Я начал задаваться вопросом, преимущества и недостатки использования каждого из них.

Предполагая, что у нас есть только одна модель для каждого вида (я знаю, что мы могли бы иметь больше, но если бы мы ограничили ее). я могу думать,

ViewModel плюсы:

  • те, упомянутые в статье.
    • Информация о представлении сохраняется в модели, предотвращая загромождение вида.
    • Информация о состоянии может использоваться совместно между видами.

минусы:

  • Невозможно вызвать метод магистрального Сохранит(), поскольку это приведет к модели, чтобы сохранить неверные данные на сервер (состояние представления для примера).
  • Невозможно вызвать метод выборки Backbone(), потому что мы можем растоптать данные наших представлений.

(Data) Модель профи:

  • Использование магистрального встроенный Сохранить, принесите и т.д.
  • представление может обмениваться данными, не заботясь о просматривать определенные данные хранятся в них.

минусы:

  • Модель может быть использована только для данных

Я правильно думать, что это?

Должен ли я иметь модель для моих данных и модель для моего вида?

Как это работает с коллекциями?

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

Любая помощь приветствуется.

ответ

2

Вы фактически предполагаете, что не можете использовать свои модели данных (домена) в задней части и что вам нужно иметь дело с вашими данными как объекты ViewModel. То, как меня научили делать опытные профессионалы области переполнения стека:

1.) Всегда используйте ViewModels для просмотра. Не используйте модели домена. Доменные модели часто не вполне подходят для просмотра, и это приводит к тому, что люди используют магические строки, запрашивают кеширование и даже сеансы для хранения информации, специфичной для просмотра, и все это не нужно.

2.) Из-за этого, ограничивая вас тем, что вы указали, например, не имея возможности использовать методы модели данных, встроенные в Backbone, используйте устройство сопоставления объектов, либо вашего собственного творения, либо другого человека, сделанного ранее , чтобы сопоставить свойства ViewModel с свойствами модели Data, когда вам нужно ее использовать.

Это позволяет вам иметь очень специфичные ViewModels, не опасаясь, что вы не сможете использовать собственные модели данных Backbone.

Что касается вашего небольшого отдельного вопроса о коллекциях, вы должны хранить коллекции объектов ViewModel для других вещей, которые вам нужны. Например, если у вас есть список автомобилей, вы должны предоставить вашему CarListViewModel список объектов CarViewModel. Если вы решите использовать объекты данных, когда вы достигнете этого далеко по лестнице моделей, он имеет более низкий эффект, но его все равно следует избегать.

+0

Спасибо. Знаете ли вы о каких-либо хороших матричных объектах/javascript? –

+0

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