2009-03-13 5 views
5

В MVVM есть много отличных примеров, но я все еще смущен.Модель и модель подключения Silverlight MVVM

Допустим, у вас есть CustomerModel и CustomerViewModel. Кажется, что было бы свойство Name в CustomerModel и одно в CustomerViewModel. Установителем в CustomerViewModel будет установлено свойство CustomerModel Name, а затем вызывается OnPropertyChanged (PropName), чтобы пользовательский интерфейс обновлялся. Это действительно так? Похоже, что геттер/сеттеры будут определены дважды. Если у вас есть модель с 50 свойствами, то это станет действительно утомительным.

Кроме того, скажем, я установил свойство Qty. ViewModel обновляет модель. Модель обновляет свойство Value на основе нового Qty. Как уведомление ViewModel уведомляется о том, что свойство Model изменилось?

ответ

2

В примере клиента, который вы даете, CustomerModel содержит всю информацию, которая хранится в вашей базе данных (или другом бэкэнд). CustomerViewModel содержит аналогичную информацию, если он будет отображаться в пользовательском интерфейсе (имя и т. Д., Возможно, еще 50 других свойств, если у вас большой класс), но так как использует интерфейс INotifyPropertyChanged, чтобы показать их как свойства, которые вид (например, XAML) может связываются с.

например.

public int Name 
{ 
    get 
    { 
     return this.name; 
    } 

    set 
    { 
     if (this.name!= value) 
     { 
      this.name= value; 
      this.OnPropertyChanged("Name"); 
     } 
    } 
} 

ViewModel также содержит другие биты состояния UI - обзорность флаги, текущий индекс Tab, более сложные биты текста, построенного из данных в нескольких областях, ObservableCollection < > из дочерних элементов и т.д. Все они там быть привязанным к XAML.

Я видел модель ViewModel, созданную из модели, как одноразовый, односторонний процесс, например. с конструктором:

CustomerViewModel viewModel = new CustomerViewModel(customer); 

или как метод расширения

CustomerViewModel viewModel = customer.ToViewModel(); 

я не видел каких-либо положений для обновления ViewModel для внесения изменений в модель - точка ViewModel является то, что она изолирована от модель. Он хранит отдельную копию данных. Он не передает изменения обратно в модель, пока вы не нажмете кнопку «Сохранить». Поэтому, если вы отменяете вместо этого, ничто в модели не изменилось, и отменить нечего.

Возможно, вы слишком стараетесь сохранить ViewModel в актуальном состоянии с помощью модели - в большинстве случаев, например, для сохранения или загрузки, вы можете просто выбросить текущий ViewModel и создать новый из текущего состояния модели. Вам нужно сохранить состояние пользовательского интерфейса ViewModel и изменить данные в нем? Это не общее требование, но это может быть сделано с помощью метода или двух, когда происходит сохранение или загрузка.

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

+0

Если вы сохраняете ViewModel отдельно от модели, как применяются любые правила в модели? Скажем, у меня есть модель с Qty и Value. Если я изменю Qty на ViewModel, который должен перейти к модели, которая обновляет значение, основанное на новом Qty. Теперь ViewModel должен показать новое значение. – 2009-03-13 11:32:07

+0

«Если я изменю Qty на ViewModel, который должен пройти до модели« нет », пока вы не нажмете кнопку« Сохранить »или тому подобное. Когда вы это сделаете, обработчик для этого должен обновить модель, сохранить ее и создать новый ViewModel из нового состояния модели. – Anthony

+0

Так что, если он не перетекает в Модель, то как ViewModel когда-либо получает обновленное поле Value? Если я изменю Qty, как пользователь, я ожидаю увидеть новое значение. MV не имеет бизнес-логики для вычисления значения, только модель. – 2009-03-13 13:15:19

5

В вашей модели ViewModel не нужно строго инкапсулировать модель. В вашем сценарии CustomerViewModel может иметь свойство Customer, которое в конечном итоге означает, что ваш View привязывается к свойствам Model ... он просто делает это через ViewModel. Это совершенно законно. Тем не менее, часто есть преимущество для инкапсуляции этого. Ваша бизнес-модель не может включать уведомление об изменении. Возможно, вы не хотите, чтобы взаимодействие пользователя изменяло бизнес-модель, пока пользователь не нажмет кнопку «ОК».Ваша бизнес-модель может проходить через исключения для плохого ввода, тогда как вы хотите использовать другую форму проверки. Я уверен, что вы можете думать о других вещах. На самом деле, я бы предположил, что большую часть времени вам понадобится инкапсуляция, так что это не очень «утомительно» в смысле простого написания множества бессмысленных ретрансляционных методов.

0

Как это сделать, отчасти зависит от вашей бизнес-модели, поскольку wekempf уже указано.

В зависимости от того, как вы отображаете информацию о клиенте в пользовательском интерфейсе, в вашем ViewModel может быть тип ObservableCollection of Customer (ваша модель). Если, например, вы показываете сценарий мастера/детали, где вы можете иметь список клиентов и показывать подробности ниже, когда выбран конкретный клиент.

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