2012-11-24 5 views
7

Wenn TL; DR: siehe letzten Absatz.Trennansichten, Befehlspräsentation (Text, Symbol) und Befehlslogik (Execute, CanExecute)

Reine WPF "schlägt vor" Präsentation (Steuerelemente, Text, Symbole) in Ansichten und Befehlslogik (Execute, CanExecute-Methoden) in Code-Behind setzen. Neben der Logik in beide Ansichten (CommandBindings) und Code-Behind ist eine verpönte Praxis, hilft es überhaupt nicht mit XAML Verdoppelung: Text, Symbole, große Symbole, Hinweise und zahlreiche andere Eigenschaften müssen dupliziert werden Jedes Mal, wenn ein Befehl verwendet wird: für Hauptmenü, für Kontextmenü, für Symbolleistenschaltfläche, für Multifunktionsleistenschaltfläche und andere Steuerelemente.

Sieht aus wie das erste Problem (wirklich Trennung von Ansichten und Logik) wird gelöst durch DelegateCommand, RelayCommand und Ansätze wie das. Befehlslogik wird in ViewModels (oder Controller im Falle von MVVMC) verschoben, Code-Behind ist sauber, keine CommandBindings und andere Unsinn in Ansichten.

Allerdings kann ich keine allgemein akzeptierte Lösung für die Präsentation Duplikation Problem finden. Ich möchte trennen Befehl Präsentation (Text, Symbole) und Befehlslogik (Execute, CanExecute Methoden). Der gesamte Code, den ich finden konnte, stellt entweder die Präsentation in Code (durch Erstellen einer RoutedCommand mit zusätzlichen Eigenschaften wie Label und Icon) oder setzt Code in die Präsentation (dh Handler in Ansichten und Code-Behind). Ich mag auch keines. Ich denke, Präsentation sollte vollständig in XAML sein, und Code sollte vollständig in CS sein (entweder in ViewModel oder Controller).

Frage: wie Ansichten trennen (XAML mit Kontrollen die Bezug Befehle), Präsentation von Befehlen (Etiketten, Icons etc. für jeden Befehl) und Logik-Befehle (C# Code für Execute, CanExecute usw. in Viewmodels oder Controller)?

+0

Zwei enge Stimmen schon? Und keine Kommentare? Ist die Frage unbeantwortbar oder habe ich etwas übersehen? Wenn Sie zum Schließen stimmen, hinterlassen Sie bitte einen Kommentar. Ich kann nicht lernen, wenn du mir nicht sagst, was ich falsch gemacht habe. – Athari

+0

Lesen Sie die "nicht konstruktive" Beschreibung in der FAQ - "diese Frage wird wahrscheinlich Debatte, Argumente, Umfragen oder erweiterte Diskussion erbitten". Aus dem gleichen Grund ist Stack Overflow kein guter Ort, um zu fragen "Wie soll ich meine Software bauen?" Fragen. –

+2

@JeanHominal So wie ich es sehe, habe ich nicht gefragt, wie ich meine Software bauen soll, ich habe nach einem Problem gefragt, das * sehr verbreitet ist *, wenn man bedenkt, wie viel Code ich gesehen habe, wo dieses Problem nicht gelöst ist , auch im Microsoft-Code. Und nach den Stimmen (5 +1 Stimmen aus 20 Ansichten), bin ich nicht die Einzige, die eine Lösung finden will. – Athari

Antwort

4

Es gibt keine integrierte Lösung für dieses Problem, Sie müssen Ihre Ärmel aufrollen und die erforderliche Struktur selbst erstellen.

In einem aktuellen Projekt, an dem ich gearbeitet habe, habe ich genau das getan. Ich habe ein Konzept namens "Aktion" erstellt, das die WPF ICommand um weitere visuelle Eigenschaften ergänzt. Es war so etwas wie dieses ...

interface IAction 
{ 
    ICommand Command { get; } 
    string DisplayText { get; } 
    string ToolTipText{ get; } 
    URI Icon { get; } 
} 

Die Anwendung eine Sammlung von Action Instanzen enthalten. Diese könnten dann an Menüs, Symbolleisten usw. gebunden werden, so dass dieselbe Instanz mit verschiedenen Präsentationsstilen wiederverwendet werden kann. Es ist alles ziemlich einfach MVVM Zeug!

Verwandte Themen