WPF ICommand 대 RoutedCommand

Question

사용자 지정 명령에 바인딩 된 Command 속성이 있습니다.

언제 ICommand을 구현해야하고 RoutedCommand에서 파생되어야합니까? 나는 그것을 보았습니다 RoutedCommand는 ICommand을 구현합니다.

어떤 경우에 ICommand을 해지해야합니까? MVVM 모델은 무엇입니까? 이 목적에 맞는 것은 어느 것인가? 당신이 RoutedCommand class다시피

Answer 1

는 ICommand 인터페이스의 구현이며, 주요 구별 경우 그 기능이 비슷하다는 RoutedEvent :

실행]와 RoutedCommand의 CanExecute 방법이 포함되어 있지 않습니다 명령에 대한 응용 프로그램 논리는 일반적인 ICommand의 경우와 동일하지만 오히려이 메서드는 CommandBinding을 사용하여 개체를 찾는 요소 트리를 가로 지르는 이벤트를 발생시킵니다. CommandBinding에 첨부 된 이벤트 핸들러에는 명령 논리가 들어 있습니다.

Execute 메서드는 PreviewExecuted 및 Executed 이벤트를 발생시킵니다. CanExecute 메서드는 PreviewCanExecute 및 CanExecute 이벤트를 발생시킵니다. 당신이 RoutedCommand 당신이 ICommand의 자신의 구현을 찾고있을거야의 동작을 원하지 않는 경우

. MVVM 패턴에 관해서는 그 하나의 솔루션을 말할 수는 없지만, 모든 사람들이 그들 자신의 방법론을 가지고있는 것처럼 보입니다. 그러나, 여기에 내가 건너 한이 문제에 대한 몇 가지 방법은 다음과 같습니다

• Using RoutedCommands with a ViewModel in WPF
• Relaying Command Logic
• Simple Command

Answer 2

유일한에게 (명령하지만 가치가 독서 릴레이 거의 동일) Rich McGuire의 대답에 추가 할 점은 RoutedCommands (및 그보다 보편적 인 하위 항목 인 RoutedUICommand은 제대로 작동하려면 이벤트 처리기로 배선해야합니다.)

대부분의 MVVM 구현 ViewModel에 대한 바인딩을 활용하려고 시도 했으므로 ViewModel (보기가 아닌)이 CanExecute/Execute 논리를 소유합니다.

대조적으로 이벤트 처리기는 해당 부담을보기로 이동합니다. 그런 다음 처리를 ViewModel로 전달할 수 있지만 이는 ViewModel과 View (캐스팅 + 메서드 호출 등) 간의 약간의 결합 정도를 의미합니다.