Как можно представить ICommand WPF в виде простой строки, которая может быть слабо связана с пользовательским интерфейсом? - PullRequest
Новая
       35

Как можно представить ICommand WPF в виде простой строки, которая может быть слабо связана с пользовательским интерфейсом?

2 голосов
/ 10 апреля 2011

В прошлом с формами Windows я использовал части Составной блок прикладного интерфейса пользовательского интерфейса в сочетании с некоторыми централизованными правилами обработки команд и безопасности, чтобы достичь слабосвязанного подхода MVC к интерфейсу для привязки к выполнению команд. Я хотел бы знать, как сделать это в WPF с ICommand или RoutedCommand?

Мои предыдущие реализации будут состоять из следующего:

  1. Свяжите каждую команду со строкой в ​​форме URI на основе REST, например, cmd: // myapp / orders / create
  2. Напишите пользовательский ICommand (не путать с WPF), который будет обрабатывать выполнение команды, у него просто есть метод Execute() и свойство CanExecute вместе с Undo() и `CanUndo, если поддерживается отмена возможности.
  3. Объекты интерфейса, необходимые для выполнения команды, будут затем свободно связаны
    1. Обработка события Click, которое не будет знать о том, какую команду выполнять, но будет просто передавать централизованное CommandManager имя команды для выполнения.
    2. Как только CommandManager получит выполнение команды, он просто использует возможности «многие ко многим» в Блок приложения составного пользовательского интерфейса , чтобы вызвать событие команды.
    3. Перед фактическим выполнением команды диспетчер команд выполняет проверку безопасности, которая в основном задает мой SecurityManager, если вошедший в систему пользователь может выполнить командную строку, правила безопасности загружаются через файл XML и состоят из шаблонов, таких как ' CMD: // MyApp / финансы / * '
    4. Как только событие команды вызывается для команды получения, оно будет отвечать за определение состояния и контекста с помощью зависимостей на основе модели представления.

Мне нравится этот подход, потому что он прост в написании, слабо связан, и командам разрешено получать состояние интерфейса только через модели представления, которые находятся через DI. Блок приложения составного интерфейса пользователя также позволил мне "включить / отключить / недоступно"

Я могу аналогичным образом реплицировать почти все, кроме «строкового» представления команды, это жизненно важно, поскольку написанный нами контекст безопасности может заблокировать целый раздел с помощью шаблонов команд, таких как cmd://myapp/finance/*, мы также можем затем позволить пользователь решает свои командные комбинации клавиш и т. д.

Ключевые требования для меня:

  1. Команды должны быть представлены в виде строк, это абсолютное требование.
  2. Должно быть в состоянии указать, что строка команды "включена", "отключена" и "недоступна" (это означает, что она должна быть скрыта в пользовательском интерфейсе.
  3. Элементы интерфейса не должны знать, как обрабатывать команду или как предоставлять контекст, это сама ответственность команд через обнаруживаемые им объекты модели представления.
  4. Выполнение команды должно быть централизованным, т. Е. Мне нужен объект диспетчера команд, который обрабатывает возникновение события для выполнения команды наряду с поддержанием стека отмены.

EDIT : Я только что подумал о том, как обеспечить привязку команды с помощью экспорта MEF для предоставления пользовательских метаданных с указанием имени команды, а затем ImportMany может загрузить их в мой CommandManager, теперь это просто вопрос

  1. Сообщая элементам интерфейса a Command String, что они вызывают, и;
  2. Разрешение изменению состояния командных строк (включено / отключено / недоступно).

РЕДАКТИРОВАТЬ 2 : Я подумал о решении, в котором мой CommandManager принимает ставку Register(Control, String), в которой можно зарегистрировать элемент управления с помощью командной строки, тогда менеджер команд может обрабатывать включение / отключение/ скрытие элементов пользовательского интерфейса при изменении их состояния и привязке к ним событий, что обеспечивает гораздо большую гибкость и развязку, а также позволяет настраивать пользователя (перемещение меню, конфигурации кнопок, сочетания клавиш и т. д.).Это вызывает беспокойство, хотя я не использую ни единой точки средства ICommand, предоставляемого WPF, в конце концов, я не думаю, что это имеет значение, но я хотел бы знать, можно ли использовать средство управления, предоставляемое с WPF.используется так просто, как я определил.Другое преимущество заключается в том, что этот метод не является специфичным для WPF и может использоваться где угодно.

1 Ответ

0 голосов
/ 10 апреля 2011

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

, но он специфичен для вашей проблемы. Я просто хотел сказать: если вы полностью пропускаете ICommand, вы определенно теряете то, что wpf делает за кулисами.Например: метод ICommands CanExecute.Менеджер WPFs запрашивает этот метод в зависимости от пользовательского ввода в ваше приложение.В противном случае вам пришлось бы обрабатывать распространение «enabled» / «disabled» / «unavailable» -State меняет себя и реализует свою собственную логику для включения / отключения кнопки.

также команды могут использоваться для более чемпросто щелкните события.

и последнее: команды могут выполняться без WPF - это просто интерфейс и явно не привязан к wpf

...