Команды MVVM и Stateful — хорошая или плохая идея?

Question

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

Я использую платформу Cinch MVVM Саши Барбера, которая включает класс SimpleCommand Марлона Греча.

Единственное, чего нет в этом классе и которого нет в некоторых других альтернативах, — это свойство Text, которое обычно можно использовать для привязки элементов пользовательского интерфейса к «Заголовку» командной операции.Поэтому я написал расширение для этого класса, которое предоставляет свойство Text.

Теперь я столкнулся со случаем использования команды для переключения подключения к устройству.Есть много разных способов реализовать это (не всегда — это программное обеспечение!).Одним из способов было бы предоставить несколько командных объектов из моей ViewModel — один для «Отключить» и один для «Подключиться»;модель представления должна предоставлять свойство, указывающее состояние соединения (IsConnected), а представление условно привязываться либо к команде Connect, либо к команде Disconnect.Моя реакция на этот вариант, однако...фу!

Вместо этого я изначально начал рассматривать не только предоставление свойства Text, но и реализацию INotifyPropertyChanged объекта команды, чтобы свойство text могло динамически изменяться моделью представления на «Подключиться» или «Отключиться» в зависимости от состояния системы.Сделав это, я могу избежать использования нескольких команд и просто предоставить один объект команды ToggleConnection.

Однако, начиная этот путь, мне пришло в голову, что могут быть и другие варианты этого шаблона, при которых пользовательский интерфейс необходимо изменять в соответствии с состоянием команды.Например, помимо изменения текста команды в зависимости от состояния соединения, у вас могут быть места, где значок должен меняться в зависимости от состояния соединения.Итак, я начал писать класс «Stateful», который реализует INotifyPropertyChanged и предоставляет два свойства — «Text» и «State».Я сделал класс универсальным, чтобы пользователь мог определить тип состояния (обычно я предпочитаю не использовать «объект», где этого можно избежать).

У меня вопрос...Как вы думаете, это хорошая или плохая идея?Это может отличаться от первоначального замысла/конструкции команд;Судя по тому, что я видел, в целом возможно, что командные объекты должны были быть без состояния, поскольку они являются «глаголами» системы.В случае с маршрутизируемыми командами, если я правильно понимаю, обычно ожидается, что только цель команды будет иметь состояние.Тем более, что одна и та же команда может быть перенаправлена ​​на разные обработчики в зависимости от того, где объявлены привязки команд.

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

Однако я имею дело не с маршрутизируемыми командами, а конкретно с командами MVVM.В этом случае в основном нет условной маршрутизации команд - представления MVVM привязываются непосредственно к объектам команд конкретной модели представления, а также к обработчикам выполнения и canexecute.

В данном случае имеет ли это смысл?

Я приложил копию рассматриваемого кода на случай, если он будет полезен/интересен.

Спасибо, Фил

Answer 1

Вам решать, с чем, по вашему мнению, будет легче работать.

Лично я не добавляю свойство .Text в свои команды просто потому, что эти команды не используются повторно.Это отличается от RoutedUICommands, представленных в платформе (или аналогичных пользовательских статических командах), поскольку они используются повторно повсюду, и если бы перевод «Выход» изменился в этой команде, это отразилось бы во всем приложении.В вашем примере этого нет - все было бы разово.

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

Я определенно с тобой по поводу двух команд — блин.Большинству делегатов кнопок, которые вы пишете, придется каким-то образом реагировать на состояние (служба, с которой вы разговариваете, не работает, эти данные должны быть заполнены таким образом, если пользователь выбрал это и т. д.), поэтому я не думаю, что неправильно иметь делегат адаптируется к информации о состоянии ViewModel.

В любом случае, это немного многословно...вывод: «делайте то, что вам удобно».

Answer 2

Как было написано на последнем плакате: «Все, что удобно».

В моем случае я обычно использую что-то вроде ДелегатКоманда.Если мне нужно привязаться к каким-то данным, я привязываюсь к виртуальной машине.Когда команда выполняется, она выполняется внутри моей виртуальной машины (через делегат, предоставленный DelegateCommand при инициализации).Тогда исполняемый делегат может или не может запустить некоторый повторно используемый код для выполнения команды.

Похоже, вы хотите использовать команду как собственную виртуальную машину.Раньше я никогда не думал об этом, но если тебе это нравится, сделай это!:)