Лучший способ создать ViewModel в MVVM

Question

Предположим, у меня есть класс с именем Customer. Теперь мне нужно визуализировать клиента. Поэтому я создал CustomerViewModel для использования в связывании. Я ищу лучший способ создать класс CustomerViewModel. Ниже приведены мои мысли по его созданию.

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

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

Итак, мне интересно, каков будет лучший способ создания модели представления? Есть ли альтернативные методы, которые лучше, чем я думал?

Answer 1

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

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

Answer 2

Вам следует прочитать статью Джоша Смита о MVVM.

У него также есть платформа под названием MVVM Foundation , которая имеет базовый класс ViewModel. В целом, я думаю, что способ, которым он реализует ViewModel, является лучшим в целом.

Answer 3

Если ваш исходный класс Customer не поддерживает привязку данных, вам придется создать класс viewmodel и реплицировать свойства класса Customer.

Если, однако, ваш класс Customer уже реализует поддержку привязки данных (он либо имеет свойства зависимости, либо реализует INotifyPropertyChanged), то нет фундаментальной причины, по которой вы не можете напрямую связываться со свойствами класса Customer.

Конечно, у вас могут быть другие соображения - вы можете захотеть, чтобы ваша view-модель выполняла определенные операции в ответ на изменения свойств, или вы не хотите, чтобы объекты Customer были изменены напрямую. В этом случае вы все равно захотите обернуть класс Customer.

Кроме того, вы можете захотеть поддерживать проверку данных через интерфейс IDataErrorInfo, и в этом случае, если ваш клиентский класс не реализует этот интерфейс, вам также, вероятно, придется обернуть его.