рефакторинга приводит к не удается разрешить символ «RoutedUICommand»

Question

Ситуация:

Я начал кодирования модели и ее команды внутри проекта WPF, теперь я решил перенести эту «модель» в библиотеке классов так оно не зависит от любого из типов WPF.

Конечная цель - использовать его в другой структуре, чем WPF, например, формы.

Для модели это было безболезненно, не было никаких зависимостей вообще на любом типе WPF, однако модель команд класса возвращает кучу ошибок: не удается разрешить символ «RoutedUICommand»

Вот выдержка из класс:

public static class MyModelCommands 
{ 
    private static readonly RoutedUICommand _addFiles; 

    static MyModelCommands() 
    { 
     _addFiles = new RoutedUICommand("Add files", "AddFiles", typeof (MyModelCommands)); 
    } 

    public static RoutedUICommand AddFiles 
    { 
     get { return _addFiles; } 
    } 

    // ... 
} 

Глядя на RoutedUICommand документации:

Выполнить и методы CanExecute на RoutedCommand г o не содержать командную команду для команды, как в случае с типичной ICommand. Методы Execute и CanExecute в RoutedCommand не содержат командную команду для команды, как в случае с типичной ICommand.

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

Но как насчет проекта WPF, должен ли я создавать фасад этого класса, который включает эти команды в RoutedUICommand (s) и обновляет мои CommandBindings для обработчиков в библиотеке классов?

Answer 1

Особенность RoutedCommand это встроено в использовании команд диспетчера

Например:

1) CommandManager.RequerySuggested поднять ICommand.CanExecuteChanged.

2) CommandManager.RegisterClassCommandBindings, чтобы связать команду с делегатами Execute и CanExecute экземпляров определенных типов.

Эти встроенные решения поставляются с небольшой стоимостью производительности, как обсуждалось здесь
A discussion about the fact that CommandManager's RequerySuggested is raised allot

(каждый раз, когда UIElement или любой из его предков получает любой UI Notification.)

Реализация вашего собственного ICommand и все еще взаимодействующий с пользовательским интерфейсом, потребует от вас вручную инициировать событие CanExecuteChanged, чтобы уведомлять объекты ICommandSource, такие как Button, чтобы поднять их команду, может выполнять делегирование.

Во-вторых, для присоединения команд развязанным образом вам необходимо реализовать какой-то объект CompositeCommand, который является своего рода агрегатором событий для команд.

Так как вы можете видеть это возможно, но все объекты ICommand предназначены для соответствия интерфейсу пользовательского интерфейса и WPF, поэтому нет смысла размещать их в другой библиотеке классов, которую вы хотели бы использовать с другим фреймом работает.

Answer 2

Класс RoutedUICommand является классом пользовательского интерфейса, который используется во мнениях и их коде позади или может просматривать модели. В ваших классах моделей не должно быть полей или свойств ICommand. Как ваши модели отображаются или редактируются в пользовательском интерфейсе, это не проблема ваших моделей. Это необходимо для разделения между слоем пользовательского интерфейса и уровнем бизнес-модели.

Когда вы следуете это шаблон, то вы можете предоставляют различные интерфейсы для одних и тех же классов моделей. Например, если вы хотите добавить пользовательский интерфейс WinForms для своих моделей, вы можете просто использовать его систему событий для обеспечения функциональности, поэтому ICommand не нужны. Вместо того, чтобы пытаться заново изобрести колесо с помощью собственной пользовательской логики команд, просто используйте любые средства, доступные на любой используемой вами Framework.