MVVM: тонкие модели представления и богатые модели

Question

Я продолжаю бороться с паттерном MVVM и, пытаясь создать практический дизайн для небольшого / среднего проекта, столкнулся с рядом проблем. Одна из этих проблем заключается в том, чтобы выяснить, как получить преимущества от развязки с этим шаблоном, не создавая много повторяющегося и сложного в обслуживании кода.

Моя текущая стратегия заключается в создании «богатых» классов модели. Они полностью осознают, что будут использоваться шаблоном MVVM, и реализуют INotifyPropertyChanged, позволяют наблюдать за своими коллекциями и знают, что за ними всегда можно наблюдать. Мои классы ViewModel, как правило, тонкие, открывают свойства только тогда, когда данные действительно нуждаются в преобразовании, причем большая часть их кода является обработчиками RelayCommand. Представления успешно привязываются либо к ViewModels, либо к моделям напрямую, в зависимости от того, требуется ли какое-либо преобразование данных. Я использую AOP (через Postsharp), чтобы облегчить боль в INotifyPropertyChanged, облегчая таким образом все мои классы моделей «обогащенными».

Существуют ли существенные недостатки при использовании этого подхода? Могу ли я предположить, что ViewModel и View настолько тесно связаны, что, если мне нужно новое преобразование данных для View, я могу просто добавить его в ViewModel по мере необходимости?

Answer 1

Я думаю, что INotifyPropertyChanged для вашей модели полезен только тогда, когда вы ожидаете, что он будет работать под управлением вашей ВМ и внешних «сил» одновременно.

Я лично сторонник моделей POCO. Внедрение в мою модель любых каркасов, специфичных для фреймворка, заставило бы меня волноваться. Когда вы помещаете событие в класс вашей модели, вы должны тщательно рассмотреть возможные проблемы с жизненным циклом вашей модели, сериализацией, хранением и т. Д. Например, что произойдет, если вы воссоздаете свой объект из источника данных и старые подписки INotifyPropertyChanged теперь недействительны?

Точно так же лучшее место для ObservableCollection находится в виртуальной машине, которая может использовать источник данных IEnumerable и представлять для просмотра только выбранные или отфильтрованные элементы ad hoc.

Answer 2

Отказ от ответственности - я не эксперт -

Я не ставлю INotifyChanged на своих моделях. Сначала я сделал это, но пришел к простому осознанию того, что INotifyChanged действительно удобен только для уведомления пользовательского интерфейса, поэтому теперь я помещаю INotifyChanged только в мои ViewModels. Это упростило управление числом «RaisePropertyChanged» ... Мои представления никогда не ссылаются на модель напрямую.

Я работаю над моим первым проектом MVVM, но над моим третьим основным рефактором: P

Answer 3

Я считаю, что это прагматичный подход - мы успешно следовали этой схеме в прошлом.

Основной предпосылкой было связать непосредственно с моделью, которая реализует INotifyPropertyChanged для большинства данных только для чтения, а затем добавить дополнительные свойства в viewmodel для просмотра конкретных вещей, которые должны быть преобразованы (как вы предложили). Для свойств, не предназначенных только для чтения, мы обнаружили, что проще всего создавать записи viewmodel (как правило, типа string), поскольку это позволяет легко добавлять проверку на стороне клиента в viewmodel.

Answer 4

Я согласен, что между View и ViewModel будет тесная связь.Но это может быть в некоторой степени облегчено с помощью IValueConverters, когда это возможно, для выполнения преобразований.

Я пытаюсь сохранить свою бизнес-логику в своей модели представления.Кроме того, я использую Viewmodel, чтобы изменить форму моей Модели, чтобы она соответствовала тому, что можно ожидать от View.