Лучший способ создать ViewModel в MVVM
Предположите, что мне назвали класс Customer. Теперь я должен представить выставленного для обозрения клиента. Таким образом, я создал CustomerViewModel использовать в привязке. Я ищу лучший способ создать CustomerViewModel класс. Следующее является моими мыслями о создании его.
1 - Создайте все свойства в клиенте снова на модели представления. Введите клиентский экземпляр в модель представления и каждого, какие свойства возвратят значение от этого клиентского объекта. Преимущество этого метода состоит в том, что я могу создать общий базовый класс для всех моделей представления и выводить общую функциональность там. Недостаток будет временем, требуемым создать все свойства снова на модели представления и выполнении обслуживания.
2 - Получите модель представления от клиента. Таким образом, у меня есть весь propeties клиента в поле зрения модель. Но это не позволит мне использовать общий базовый класс и помещать логику модели общего представления там.
Таким образом, я задаюсь вопросом, каков будет лучший метод для создания модели представления? Есть ли какие-либо альтернативные методы, которые лучше, чем, что я думал?
3 ответа
Вам следует прочитать статью Джоша Смита о MVVM.
У него также есть фреймворк под названием MVVM Foundation, который имеет базовый класс ViewModel. В общем, я думаю, что способ, которым он реализует ViewModel, является лучшим в целом.
.Если ваш оригинальный класс Клиента не поддерживает привязку данных, то вы будете вынуждены создать класс Viewmodel и скопировать свойства класса Клиента.
Если же ваш класс Клиента уже реализует поддержку привязки данных (он либо имеет зависимые свойства, либо реализует INotifyPropertyChanged), то нет фундаментальных причин, по которым вы не можете напрямую привязываться к свойствам класса Клиента.
Конечно, у вас могут быть и другие соображения - вы можете захотеть, чтобы ваша viewmodel выполняла определенные операции в ответ на изменение свойств, или вы можете не хотеть, чтобы объекты Клиента изменялись напрямую. В этом случае вы всё равно захотите обернуть класс Customer.
Также вы можете захотеть поддержать проверку данных через интерфейс IDataErrorInfo. В этом случае, если ваш класс клиента не реализует этот интерфейс, вам, скорее всего, тоже придётся его обернуть.
.Вариант 1 гораздо лучше. Причина в том, что вы хотите иметь возможность варьировать эти два слоя независимо друг от друга. Наличие тесной связи между вашей доменной моделью и вашей моделью представления введет жесткость в процесс разработки, которую вы хотите избежать.
Способ, которым я сталкиваюсь с необходимостью писать так много кода, заключается в том, что я этого не делаю. Я использую T4 шаблоны , некоторые разумные условности (свойства, по умолчанию, отображаются в модели представления; классы доменной модели реализуют INotifyPropertyChanged , и они делегируются вверх), а также конфигурационный файл для работы с проекцией/раскладыванием и генерацией моделей представления. Я также генерирую их как частичные классы, чтобы иметь возможность иметь дело с добавлением в них другого кода по мере необходимости.