WPF - Wo zeichnen Sie die Linie zwischen Code und XAML?

Question

Ich bin ein langjähriger C# /. NET Programmierer, aber völlig neu in WPF und dem System.Windows.Controls Namespace und XAML. Je mehr ich darüber lerne, desto mehr wird mir klar, dass Sie praktisch alle Ihre GUI-Initialisierungs- und Event-Handling-Kleister entweder in XAML oder in Code (sagen wir C# -Code oder VB.Net-Code) ausführen können.

Meine Frage ist an diejenigen, die länger an WPF gearbeitet haben und im Idealfall an diejenigen, die Apps damit ausgeliefert haben. Wo haben Sie den besten Weg gefunden, um zwischen XAML und Code zu unterscheiden? Haben Sie XAML verwendet, wo immer Sie konnten? Nur in Verbindung mit nichtkodierenden UI-Designern?

Alle Tipps in diesem Bereich wären sehr hilfreich für mich selbst und andere Programmierer, die gerade in WPF Programmierung gehen und sind durch alle Entscheidungen, die wir treffen können, irgendwie gelähmt!

Answer 1

Ein Tipp ist, Ereignishandler in XAML nicht zu deklarieren. Benennen Sie stattdessen Ihre Elemente und fügen Sie Ereignishandler in den Code-Behind ein. Dies trägt zu einer sauberen Trennung zwischen Designer und Entwickler bei.

Answer 2

Ein weiterer Tipp ist XAML in funktionelle und ästhetische zu trennen. Entwickler würden normalerweise im funktionalen XAML arbeiten, während Designer in erster Linie auf die Ästhetik achten. Dies hält den funktionalen XAML sehr einfach zu ranken, was wichtig ist, da Entwickler oft solche XAML bearbeiten müssen. Aesthetic XAML wird in der Regel von Designern mit Tools bearbeitet, so dass ihre Ordentlichkeit und Ausführlichkeit weniger ein Problem darstellt.

Ich habe vor einiger Zeit ein wenig von einem Blog-Post here.

Answer 3

Beim Erstellen von UserControls versuche ich so viel wie möglich zu Xamlize.

Ein Tipp, den ich in dem Gebiet gefunden, dass ControlTemplate und DataTemplates von Hand zu schaffen ist wirklich ein Schmerz in den *** ... Ich habe immer diejenigen, die in XAML schreiben ....

Answer 4

Eine Sache, die ich Sehen Sie sich das Model-View-View-Modell an. Es ist ein sehr elegantes Muster, das natürlich alles in schöne Eimer ... einschließlich Ihres xaml trennt.

Zum Beispiel hilft es Ihnen, eine klare Grenze zwischen dem Entwickler und dem Designer zu halten und sogar eine testgetriebene Entwicklung zu ermöglichen.

Es gibt eine ganze Reihe von Informationen da draußen, aber ich würde mit John Gossman Blog-Beiträge beginnen:

• http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx
• http://blogs.msdn.com/johngossman/archive/2005/10/09/478894.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/26/539598.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/27/540304.aspx
• http://blogs.msdn.com/johngossman/archive/2006/03/04/543695.aspx
• http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx

Update: Ich will nur Menschen mit vielen guten Informationen über M-V-VM in es auf einem anderen Stackoverflow post zeigen.

Answer 5

Wenn Sie ein richtiges Muster wie Mode-View-ViewModel folgen, erhalten Sie die Möglichkeit, mehr auf XAML-Seite und weniger auf Code hinter zu tun.Maximieren Sie die Verwendung von RoutedEvents und Befehle in WPF-Code.

Answer 6

Wie andere vorgeschlagen haben, versuchen Sie, dem Model-View-ViewModel-Muster zu folgen. Es ist jedoch in Ordnung, Sachen in den Codebehind zu legen! Die Regel ist, dass, wenn es "View" verwandt ist, Sie es in den Xaml oder den Codebehind setzen (was auch immer bequemer für Sie ist). Wenn es mehr Geschäftslogik in Bezug darauf gibt, wie der Benutzer mit dem System interagiert, gehört es in das ViewModel. Wenn es sich nur um Geschäftslogik handelt, die sich nicht mit Interaktion befasst, gehört sie in das Modell.

Beispiele jeder wäre:

• Modell: definiert eine Eigenschaft namens ModifiedDate, die das letzte Mal speichert er geändert wurde.

• Ansichtsmodell: wandelt die ModifiedDate in eine Aufzählung Eigenschaft namens ModifiedAge, basierend auf, wenn es geändert wurde: Gestern, in der letzten Woche, im letzten Monat, im letzten Jahr, usw.

• Ansicht: wandelt die ModifiedAge-Eigenschaft in eine Hintergrundfarbe um, in der Daten, auf die zuletzt zugegriffen wurde, hellgelb hervorgehoben werden und weniger kürzlich aufgerufene Daten eher von einem Beige-Khaki-Grau sind, das von Ihrem Designer als "Meadow Lark Lilly Flowerpot" bezeichnet wird.

Answer 7

ich Gebrauch so viel XAML möglich sagen würde, mit Binding, commands, styles, templates usw. hatte ich Funktionalität von Speichern und Laden von Vorlagen für die Kontrollen mehr XAML XamlReader/XamlWriter und es einfacher zu unterstützen haben.

Answer 8

Vergessen Sie nicht, dass XAML den Code hat. Es ist deklarativ und all das, aber es ist immer noch eine Programmiersprache. Tatsächlich wird eine Konvertierung in C# oder Visual Basic durchgeführt, bevor es in IL umgewandelt wird, damit der .NET-Compiler kauen kann.

Ich werde Scott Whitlocks Kommentar wiederholen: MVVM ist eine gute Möglichkeit, Bedenken zu trennen und sich auf architektonische Details zu konzentrieren. Es ist wirklich, wirklich OK, Sachen in deinen Code-hinten zu setzen, besonders die Sachen, die er beschreibt. Wenn Sie Designer und Entwickler nicht trennen müssen, passen Sie das MVVM-Muster an Ihre speziellen Anforderungen an. Versuche nicht, dich dazu zu zwingen, rein oder idealistisch zu sein.

Es ist auch vollkommen in Ordnung, Aufrufe an die Methoden Ihres ViewModels direkt in den View-Code dahinter zu stellen, wenn Sie nicht die Flexibilität der Kommandierung mit ICommand-Klassen benötigen. Oder wenn Sie wissen, dass die Ansicht, die Sie erstellen, immer an die ViewModel-Klasse gebunden ist, die Sie erstellen. Oder Sie könnten einen Schritt weiter gehen, eine Schnittstelle für Ihr ViewModel definieren und nur an Implementierungen dieser Schnittstelle binden. Dann können Sie das ViewModel immer noch austauschen, wann immer Sie möchten.

Zeug wie das.