MVVM에서 WPF 명령에 대해 허용되는 패턴은 무엇입니까?

Question

WPF 앱에서 작업하고 있는데 명령 패턴을 잘 이해하고 있지만 MVVM의 명령 패턴에 대한 여러 가지 구현이 있다는 것을 알았습니다. WPF 샘플 앱에는 Josh Smith의 구현이 있고, 프리즘의 DelegateCommand과 CommandBindings 구현이 있습니다.

제 질문은 MVVM에서 명령을 사용하기 위해 일반적으로 받아 들여지는 최선의 방법은 무엇입니까? 내 응용 프로그램은 프리즘을 사용하므로 DelegateCommand을 사용할 수 있습니다.

내 팀의 개발자는 어떤 접근 방식이 "최고"인지에 대해 논쟁하고 있습니다. 어떤 사람들은 각 명령에 대해 생성 된 수많은 .cs 파일을 좋아하지 않는 사람도 있고, 모두가 CommandBindings을 통해 유선 연결되는 것을 선호하는 사람도 있습니다. 나는 잃어 버렸다. 누구든지 약간의 빛을 비추 수 있습니까?

Answer 1

두 점을 고려할 : 같은 CommandSinkCommand 또는 (신치에서) SimpleCommand 같은 다른 MVVM 프레임 워크에서 제공

명령 등의 작업을 정상 ICommands이처럼. 특히 CanExecute 처리기는 UI 변경을 유발할 수있는 문제가 WPF에서 발생했다고 판단 할 때마다 평가됩니다. 수동으로 이것을 CommandManager.InvalidateRequerySuggested()을 통해 강제로 수행 할 수도 있습니다.

이와 대조적으로 프리즘의 DelegateCommands <>은 수동으로 RaiseCanExecuteChanged()을 호출하지 않는 한 CanExecute 처리기를 호출하지 않습니다. 이 그것은 또한 명령이 정상적으로 다시 쿼리 할 때 트리거됩니다 있도록 변경하고자하는 경우, http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338

편집에 코드를 참조하십시오

두 번째 포인트 : MVVM 프레임 워크의 명령은 일반적으로 명령 매개 변수로 객체를 받아 들인다. 대조적으로 Prism의 DelegateCommands <>은보다 강력하게 입력됩니다 (원한다면 물론 DelegateCommands를 가질 수도 있지만).

Answer 2

글쎄 - 해결책이 없다고 생각합니다.

CommandBindings는 쉽게 테스트 할 수 없으며 ViewModel의 WPF 클래스에 종속되지 않습니다. 그다지 좋지 않습니다. 그래서 나는 그들을 사용하지 않을 것이다.

DelegateCommand 및 CommandSinkCommand (조쉬 스미스의 솔루션) 모두 IMO에 좋은 방법입니다. 그들은 정말로 다르지 않고 그들 중 누구도 다른 것과 우월하지 않습니다. CommandSink 버전은 명령 라우팅이 더욱 복잡해지면 항상 작동하지 않습니다 (특히 DataTemplates가 관련된 경우).

다음과 같이 결합 할 수도 있습니다. DelegateCommand를 사용하고 JoshSmith 버전을 추가적으로 사용할 수 있으므로 두 가지의 장점을 결합 할 수 있습니다. 당신이 필요로하는 것은 도우미 클래스 뿐이며 구현하기가 어렵지 않습니다.

응용 프로그램에서 더 중요한 것은 다음과 같습니다. 사용하려는 것을 결정한 경우 전체 응용 프로그램을 통해이 방법을 따라야합니다.