Модель связывания Silverlight MVVM и модель представления

Question

В MVVM есть много отличных примеров, но я все еще в замешательстве.

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

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

Answer 1

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

Answer 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 также содержит другие биты состояния пользовательского интерфейса - флаги видимости, текущий индекс табуляции, более сложные биты текста, построенные из данных в нескольких полях, ObservableCollection <> дочерних элементов и т. Д. Все они должны быть связаны с XAML.

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

  CustomerViewModel viewModel = new CustomerViewModel(customer);

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

  CustomerViewModel viewModel = customer.ToViewModel();

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

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

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

Answer 3

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

В зависимости от того, как вы отображаете информацию о клиенте в вашем пользовательском интерфейсе, у вас может быть ObservableCollection типов клиентов (вашей модели) в вашей модели представления. Например, если вы отображаете сценарий «основной / подробный», в котором у вас может быть список клиентов и ниже показаны подробности, когда выбран конкретный клиент.