Рефакторинг чрезмерно увеличенного в размерах ViewModel
Я пишу приложение PRISM/MVVM/WPF. Это - Приложение отделов организации, таким образом, существует много сложных правил. Я заметил, что Модель Представления начинает быть чрезмерно увеличенной в размере. Существует два основных вопроса.
Каждый - это для поддержания MVVM, я делаю много вещей, которые чувствуют hacky как добавление набора свойств к моему VM. Представление связывает с теми свойствами для отслеживания то, что чувствует себя подобно представлению определенная информация. Например, булево отслеживание состояния длительного процесса в VM, таким образом, представление может отключить некоторые свои средства управления, в то время как длительный процесс работает. Я считал, что эта проблема могла быть решена с Приложенными Поведениями. Я больше изучу это. В примере приложения MVVM Вы видите онлайн, это не грандиозное предприятие, потому что они упрощены.
Другой проблемой является количество команд в моем VM. Прямо сейчас существует четыре команды. Я определяю команды в VM использование RelayCommand Josh Smith (в основном DelegateCommand в ПРИЗМЕ) так все жизни бизнес-логики в VM. Я рассмотрел перемещение каждой команды в отдельную единицу работ. Я не уверен лучший способ сделать это.
Какие шаблоны - Вы парни, использующие для хранения VMs чистым? Я могу уже чувствовать, что кто-то отвечает "Вашим представлением, и VM является слишком сложным, необходимо повредить их во многие view/VMs". Это, конечно, не слишком сложно с точки зрения Ux - существует 2 кнопки, поле комбинированного списка и поле списка. Кроме того, с логической точки зрения это - один связный домен. Однако я очень интересуюсь слушанием, как другие имеют дело с этим типом проблемы.
Спасибо за Ваш вход.
2 ответа
Я чувствую вашу боль. Я много борюсь с такими вопросами, когда работаю над приложениями MVVM. На днях я отправлю подробный список вопросов, чтобы узнать мнение других, как вы.
Я склонен очень беспокоиться о «раздувании» в моем базовом классе ViewModel, но не так сильно в конкретных подклассах ViewModel. Часто возникает соблазн добавить зависимость, используемую 2-3 ViewModels, в базовый класс, но этого следует избегать.
Хотя я не могу предположить, что знаю, что вы думаете о раздувании, я могу сказать, что не думаю, что наличие свойства «занято» или команд, обрабатываемых в виртуальной машине, - это плохо. Вы можете подумать над тем, может ли ViewModel заниматься сразу несколькими делами. Если это так, вы можете пойти дальше и подумать о том, как его разорвать. Хотя я лично не видел этого на практике, вы, вероятно, могли бы привязать к нему свой единый, целостный вид и пару ViewModels.
Если у вас длинные команды или они могут быть выполнены для разных целей, я думаю, что создание команд самоисполняющихся модулей - хорошая идея. Но, вероятно, лучше придерживаться этого подхода, чтобы не сбивать с толку тех, кто будет работать над ним позже. Например, если у вас есть класс SaveCustomerCommand, состоящий примерно из 10 строк кода, вы, вероятно, не захотите использовать RelayCommand для всего остального.
Было бы неплохо, если бы существовали жесткие правила для подобных вещей, но я думаю, что и структура, и шаблон все еще находятся в стадии эволюции прямо сейчас.
Не зная специфики ViewModel, трудно сказать, откуда берется раздутость. Это может быть не связано с пользовательским интерфейсом, например, слишком много строк для запроса модели. Или это могут быть функции пользовательского интерфейса, которые лучше реализовать в пользовательском интерфейсе с помощью триггеров или чего-то еще.
Не могли бы вы подробнее рассказать о вашей ViewModel?
EDIT На основе комментариев.
SaveCustomer и DeleteCustomer звучат как методы модели или сервиса, поэтому я бы поместил их в какой-то слой постоянства.
Upload/Download Customer Video: Опять же, эти методы не являются специфичными для ViewModel (вы можете захотеть сделать их в другой ViewModel), поэтому я бы поместил их в Web Service и попросил команду ViewModel вызывать его.
В целом, стоит поместить общий код (который могут захотеть использовать несколько ViewModel) в службу, а затем бросить эту службу в ваш IOC. Таким образом, ваши ViewModel становятся легкими "директорами" информации от View к Model или Service.