Wenn TL;DR: siehe den letzten Absatz.
Pure WPF "schlägt" vor, die Darstellung (Steuerelemente, Text, Symbole) in Ansichten und die Befehlslogik (Execute-, CanExecute-Methoden) in Code-Behind zu packen. Neben dem Einfügen der Logik in Ansichten ( CommandBindings ) und Code-Behind eine verpönte Praxis ist, hilft es überhaupt nicht mit XAML-Duplizierung Text, Icons, große Icons, Hinweise und zahlreiche andere Eigenschaften müssen jedes Mal vervielfältigt ein Befehl verwendet wird: für das Hauptmenü, für das Kontextmenü, für die Schaltfläche in der Symbolleiste, für die Ribbon-Schaltfläche und andere Steuerelemente.
Es sieht so aus, als ob das erste Problem (echte Trennung von Ansichten und Logik) gelöst wird durch DelegateCommand , RelayCommand und ähnliche Ansätze. Die Befehlslogik wird in ViewModels (oder Controller im Falle von MVVMC) verschoben, der Code-Behind ist sauber, keine CommandBindings und anderen Unfug in Ansichten.
Ich kann jedoch keine allgemein akzeptierte Lösung für das Problem der doppelten Darstellung finden. Ich möchte trennen Befehlsdarstellung (Text, Icons) und Befehlslogik ( Execute , CanExecute Methoden). Der gesamte Code, den ich finden konnte, fügt entweder die Präsentation in den Code ein (indem er eine RoutedCommand mit zusätzlichen Eigenschaften wie Label y Icon ), oder setzt Code in die Präsentation (d.h. Handler in Views und Code-Behind). Beides gefällt mir nicht. Ich denke, die Präsentation sollte vollständig in XAML sein, und der Code sollte vollständig in CS sein (entweder im ViewModel oder Controller).
Frage: wie man Ansichten (XAML mit Steuerelementen, die auf Befehle verweisen), die Darstellung von Befehlen (Beschriftungen, Symbole usw. für jeden Befehl) und die Logik von Befehlen (C#-Code für Execute , CanExecute etc. in ViewModels oder Controllern)?
