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

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

например.

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

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

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

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

  CustomerViewModel viewModel = new CustomerViewModel(customer);

или как дополнительный метод

  CustomerViewModel viewModel = customer.ToViewModel();

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

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

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

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

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

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