MVVM: тонкий ViewModels и богатые модели
Я продолжаю бороться с шаблоном MVVM и в попытке создать практический дизайн для маленького/среднего проекта, столкнулись со многими проблемами. Одна из этих проблем выясняет, как извлечь пользу из отделения с этим шаблоном, не создавая много повторяющегося, твердо обслуживаемого кода.
Моя текущая стратегия состояла в том, чтобы создать 'богатые' Образцовые классы. Они полностью осведомлены, что они будут использованы шаблоном MVVM и реализацией INotifyPropertyChanged, позволить их наборам наблюдаться и оставаться осведомленными, что они могут всегда являться объектом наблюдения. Мои классы ViewModel имеют тенденцию быть тонкими, только выставляя свойства, когда данные на самом деле должны быть преобразованы с объемом их кода быть обработчиками RelayCommand. Представления счастливо связывают или с ViewModels или с Моделями непосредственно, в зависимости от того, требуется ли какое-либо преобразование данных. Я использую AOP (через Пострезкий) для упрощения боли INotifyPropertyChanged, помогая сделать все мои Образцовые классы 'богатыми' таким образом.
Там значительные недостатки к использованию этого подхода? Я могу предположить, что ViewModel и Представление так сильно связываются, что, если мне нужно новое преобразование данных для Представления, я могу просто добавить его к ViewModel по мере необходимости?
4 ответа
Я думаю, что INotifyPropertyChanged в вашей модели полезен только тогда, когда вы ожидаете, что он будет управляться вашей виртуальной машиной и внешними «силами» одновременно.
Я лично сторонник моделей POCO. Внесение в мою модель каких-либо каркасов, специфичных для фреймворка, заставило бы меня волноваться. Когда вы помещаете событие в свой класс модели, вы должны тщательно рассмотреть возможные проблемы с жизненным циклом вашей модели, сериализацией, хранением и т. Д. Например, что произойдет, если вы воссоздадите свой объект из источника данных, а старые подписки INotifyPropertyChanged теперь недействительны?
Аналогично, лучшее место для ObservableCollection - это виртуальная машина, которая может использовать источник данных IEnumerable и представлять в представление только выбранные или специально отфильтрованные элементы.
Я согласен с тем, что между View и ViewModel будет тесная связь. Но это можно в некоторой степени облегчить, если по возможности использовать IValueConverters для преобразований.
Я стараюсь сохранить свою бизнес-логику в своей ViewModel. Кроме того, я использую Viewmodel, чтобы изменить форму моей модели, чтобы она соответствовала той, которую может ожидать View.
Я считаю это прагматическим подходом - мы следовали этому шаблону успешно в прошлом.
Основная предпосылка заключалась в том, чтобы напрямую привязаться к модели, которая реализует INotifyPropertyChanged для большинства данных только для чтения, а затем добавить дополнительные свойства в модель просмотра для конкретных материалов, которые необходимо преобразовать (как вы предложили). Для свойств, не предназначенных только для чтения, мы обнаружили, что проще всего создать записи модели просмотра (обычно строки типа), поскольку это позволяет легко добавлять проверку на стороне клиента в модель просмотра.
Отказ от ответственности - я не эксперт -
Я не использую INotifyChanged на своих моделях. Сначала я сделал это, но пришел к простому осознанию того, что INotifyChanged на самом деле практичен только для уведомления пользовательского интерфейса, поэтому сейчас я помещаю INotifyChanged только в свои ViewModels. Это упростило управление количеством RaisePropertyChanged ... Мои представления никогда не ссылаются на Модель напрямую.
Я работаю над своим первым проектом MVVM, но еще над третьим крупным рефакторингом: P