This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: WPF: x:Code Element - eine Diskussion
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
An diesem Beispiel ist zu sehen, dass ein Button definiert wurde. Dieser reagiert auf das Click-Ereignis. Anstatt nun einen Eventhandler zu setzen, welcher in der Code-Behind-Datei behandelt wird, wird dieser über x:Code direkt im XAML behandelt.
Hinweise zum x:Code Element
Der Vollständigkeit halber, hier ein paar Hinweise zu diesem Element.
Da hier Code direkt in XAML eingefügt wird, sollte normalerweise ein CDATA verwendet werden. Hintergrund ist, dass beispielsweise das Einfügen von < und > zu einem invaliden XML führen würde - und XAML ist ja im Endeffekt uach nur XML. Im obigen Beispiel wurde CDATA weggelassen, da kein spezielles Zeichen vorkommt.
Weiters gibt es bei der Verwendung von x:Code einige Limitierungen. Bei der Kompilierung wird sämtlicher Code innerhalb eines x:Code Elements als Teil der dahinterliegenden partiellen Klasse angesehen. Daher ist es nicht möglich, zusätzliche Klassen zu definieren (ausser nested Classes). Wird auf Entitäten ausserhalb der partiellen Klasse verwiesen, kann dies nur voll qualifiziert passieren.
Resultierende Probleme
Aus der Verwendung des x:Code Elements ergeben sich einige Probleme, die es zu wissen gilt.
Interpretierung/Kompilierung Anwendungen, die XAML-Code interpretieren, müssen darin enthaltenen Sourcecode kompilieren können. Dies ist jedoch nicht immer der Fall. Beispielsweise kann dies der Internet Explorer nicht, Visual Studio hingegen schon. Dies bedeutet, dass obiger Code nicht im IE funktionieren würde, da die notwendigen Assemblies nicht im Hintergrund generiert werden können.
Trennung Design und Implementierung WPF besitzt den Vorteil, dass Design und Implementierung voneinander getrennt werden können. Bei entsprechenden Ressourcen kann als XAML durch einen Designer aufbereitet werden, während ein Entwickler die tatsächliche Implementierung vornimmt. Wird nun das x:Code Element verwendet, wird der Präsentationsteil mit der Logik verbunden, was zum einen eine hohe Koppelung bringt und zudem einen wesentlich erhöhten Wartungsaufwand. Selbst Microsoft weist darauf hin:
In terms of architecture and coding philosophy, maintaining a separation between markup and code-behind keeps the designer and developer roles much more distinct.
Limitierung Da für das x:Code Element (wie oben beschrieben) Limitierungen bestehen, kann kaum etwas ernsthaftes in ein XAML eingebettet werden.
Daher stellt sich die grundsätzliche Frage, warum es dieses Element überhaupt gibt, da es schlussendlich verleitet, eben mal schnell dann doch den Code direkt ins XAML zu schreiben.
Fazit
Warum es das x:Code Element gibt, kann schwer beantwortet werden. Möglicherweise gibt es einen guten Grund, welcher sich mir im Moment entzieht. In der Praxis sollte dieses Element jedoch nicht verwendet werden. Selbst für eine kurze Demonstration sollten man doch lieber zur sauberen Variante greifen.