2013-04-11 2 views
1

Этот вопрос больше связан с тем, как структурировать код или, точнее, ответственность моделей в шаблоне MVVM с помощью Knockout. Я использую Knockout с Durandal, но вопрос может быть общим вопросом для шаблона MVVM. Для напримерОтветственность модели в MVVM

У меня есть модель, как, например:

var Model = function(data){ 
     this.name = data.name; 
     this.count = ko.observable(); 
}; 

Model.prototype.getCount = function(){ 
     var self = this; 
     setInterval(function(){ 
      //some ajax call to get the count 
      self.count(data.count); 
     }, 1000); 

}; 

Мой ViewModel принимает коллекцию моих моделей, таких как:

var ViewModel = function(){ 
     this.models = ko.observableArray([]); 
     //ajax call to get the required data 
     data.Items.forEach(function(item){ 
      var model = new Model(item);  
      model.getCount(); 
      this.models.push(model); 
     } 
}; 

А теперь мой взгляд

<div data-bind="foreach: models"> 
    <div data-bind="text: name"></div> 
    <div data-bind="text: count"></div> 
</div> 

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

Так должен ли код, относящийся к обновлению счета, по существу getCount, жить на модели-модели и модели - это не подходящее место для этого. Где различие того, какой код должен оставаться в поле зрения модели или модели.

+3

Модель представляет собой объекты в вашей системе, тогда как ViewModel - это модель для пользовательского интерфейса. Модель должна взаимодействовать с постоянством/backend, чтобы обновить себя. ViewModel создаст мост между моделью и интерфейсом (2 пути). бэкенд <-> Модели <-> ViewModel <-> Посмотреть –

+0

Моя модель в вышеуказанном случае взаимодействует с сервером для обновления этого значения счетов плюс он также имеет наблюдаемое свойство, которое имеет два способа связывания с точкой зрения. Но после чтения ниже ответа я более склонен думать о нем как viewModel. Пожалуйста, поправьте меня, если я ошибаюсь. – nimgrg

+1

для привязки UI, ваша модель и ViewModel являются ViewModel. Однако не забывайте, что модель является моделью домена, например. User, Product и т. Д., Тогда как ViewModel специфичен для пользовательского интерфейса. –

ответ

2

Я бы оценил вашу модель как модель представления, если быть честным. Ваша модель - это объекты json, которые вы возвращаете из своего вызова Ajax, и вы создаете модель представления для каждого из них. Насколько мне известно, нет проблем с наличием вложенных моделей представлений.

+0

Я задумался над всей концепцией и вашим ответом плюс с другими, помог мне скрыть сомнения и смуты, которые у меня были. Благодаря!! – nimgrg

1

Нокаут действительно не реализует MVVM; это больше похоже на VVM. Другие библиотеки, такие как Backbone и др., Используют модели; Нокаутом действительно нет. Ваша «модель» для MVVM в «Нокауте» - это ваша база данных базы данных на стороне сервера.

+0

Предоставлено, что объект на стороне сервера является моделью, но вы можете украсить этот объект большим количеством свойств (вычисляемых и т. Д.). Ваша модель просмотра - это, по существу, мост между этой моделью и вашим представлением, поэтому действия на представлении будут обрабатываться с помощью модели viewmodel, и она отвечает за внесение изменений в базовую модель. Таким образом, ViewModel - это то, что содержит модель и делает ее доступной для представления. Следовательно, Mode-View-ViewModel. Вы согласны? –

+0

Я думаю, что вы смотрите скорее на преобразование, чем на истинную модель. Если вы передадите модель в представление и «украсите ее», или даже если вы ее вообще не модифицируете (хотя это было бы странно), она по-прежнему остается «моделью просмотра», а не моделью. Возможно, вы можете сделать аргумент о том, что он на короткое время существует на стороне клиента при создании экземпляра модели представления, но это в значительной степени выбрасывается впоследствии. Чтобы обновить модель, вы будете выпускать AJAX POST для изменения серверной стороны, * не * некоторой ее клиентской версии. –

+0

Правильно положил. Я согласен. –

Смежные вопросы