XAMLServices-Klasse und grundlegende XAML-Lese- und -Schreibvorgänge
XamlServices ist eine von .NET Framework-XAML-Diensten bereitgestellt Klasse, die verwendet werden kann, um XAML-Szenarios zu adressieren, die keinen bestimmten Zugriff auf die Informationen zum XAML-Knotenstream/XAML-Typsystem erfordern, oder die aus diesen Knoten abgerufen werden. Die XamlServices-API kann wie folgt zusammengefasst werden: Load oder Parse, um einen XAML-Ladepfad zu unterstützen, Save, um einen XAML-Speicherpfad zu unterstützen, und Transform um eine Technik bereitzustellen, die einen Ladepfad und einen Speicherpfad verbindet. Transform kann verwendet werden, um von einem XAML-Schema zu einem anderen zu wechseln. In diesem Thema sind diese API-Klassifizierungen zusammengefasst, und die Unterschiede zwischen bestimmten Methodenüberladungen werden beschrieben.
Dieses Thema enthält folgende Abschnitte.
- Laden
- Parse
- Speichern
- Transform
- Verwandte Abschnitte
Laden
Verschiedene Überladungen von Load implementieren die vollständige Logik für einen Ladepfad. Der Ladepfad verwendet XAML und gibt einen XAML-Knotenstream aus. Die meisten dieser Ladepfade verwenden XAML in Form einer codierten XML-Textdatei. Sie können jedoch auch einen allgemeinen Stream laden oder eine vorab geladene XAML-Quelle, die bereits in einer anderen XamlReader-Implementierung enthalten ist.
Die einfachste Überladung für die meisten Szenarios ist Load(String). Diese Überladung verfügt über einen fileName-Parameter, bei dem es sich einfach um den Namen einer Textdatei handelt, die die zu ladende XAML enthält. Dies eignet sich für Anwendungsszenarios wie Anwendungen mit voller Vertrauenswürdigkeit, die zuvor den Zustand oder Daten in den lokalen Computer serialisiert haben. Dies ist auch für Frameworks nützlich, bei denen Sie das Anwendungsmodell definieren und eine der Standarddateien, die Anwendungsverhalten, die beim Start angezeigte Benutzeroberfläche oder andere vom Framework definierte Funktionen definieren, laden möchten.
Load(Stream) hat ähnliche Szenarios. Diese Überladung kann nützlich sein, wenn Sie zu ladende Dateien vom Benutzer auswählen lassen, da ein Stream eine häufige Ausgabe von anderen System.IO-APIs ist, die auf ein Dateisystem zugreifen können. Oder Sie könnten über asynchrone Downloads oder andere Netzwerktechniken, die ebenfalls einen Stream bereitstellen, auf XAML-Quellen zugreifen. (Das Laden aus einem Stream oder einer vom Benutzer ausgewählten Quelle hat Auswirkungen auf die Sicherheit. Weitere Informationen finden Sie unter XAML-Sicherheitsüberlegungen.)
Load(TextReader) und Load(XmlReader) sind Überladungen, die Reader für Formate aus früheren Versionen von .NET Framework erfordern. Zum Verwenden dieser Überladungen sollten Sie bereits eine Readerinstanz erstellt und deren Create-API verwendet haben, um die XAML in der relevanten Form (Text oder XML) zu laden. Wenn Sie bereits Datensatzzeiger in die anderen Reader verschoben oder andere Vorgänge damit ausgeführt haben, spielt dies keine Rolle. Die Ladepfadlogik aus Load verarbeitet immer die gesamte XAML-Eingabe vom Stamm abwärts. Für diese Überladungen sind folgende Szenarien denkbar:
Entwurfsoberflächen, auf denen einfache XAML-Bearbeitungsfunktion eines vorhandenen XML-spezifischen Text-Editors bereitgestellt werden.
Varianten der System.IO-Kernszenarien, in denen zum Öffnen von Dateien oder Streams dedizierte Reader verwendet werden. Die Logik überprüft oder verarbeitet den Inhalt rudimentär, bevor er als XAML geladen wird.
Sie können eine Datei, einen Stream, einen XmlReader, TextReader oder XamlReader laden, von der bzw. dem die XAML-Eingabe durch das Laden mit den Reader-APIs umschlossen wird.
Intern ist jede der oben genannten Überladungen letztlich Load(XmlReader), und der übergebene XmlReader wird verwendet, um einen neuen XamlXmlReader zu erstellen.
Die Load-Signatur für erweiterte Szenarien ist Load(XamlReader). Sie können diese Signatur für einen der folgenden Fälle verwenden:
Sie haben eine eigene Implementierung von einem XamlReader definiert.
Sie müssen Einstellungen für XamlReader angeben, die von den Standardeinstellungen abweichen.
Beispiele für nicht standardmäßige Einstellungen sind Folgende: AllowProtectedMembersOnRoot; BaseUri; IgnoreUidsOnPropertyElements; LocalAssembly; ValuesMustBeString. Der Standardreader für XamlServices ist XamlXmlReader. Wenn Sie einen eigenen XamlXmlReader mit Einstellungen zur Verfügung stellen, werden mit folgenden Eigenschaften nicht standardmäßige Einstellungen festgelegt: XamlXmlReaderSettings, CloseInput; SkipXmlCompatibilityProcessing; XmlLang; XmlSpacePreserve.
Parse
Parse entspricht Load, da es sich um eine Ladepfad-API handelt, die einen XAML-Knotenstream aus der XAML-Eingabe erstellt. In diesem Fall wird die XAML-Eingabe jedoch direkt als Zeichenfolge bereitgestellt, die das gesamte zu ladende XAML enthält. Parse ist ein einfacher Ansatz, der sich besser für Anwendungsszenarien eignet als für Frameworkszenarien. Weitere Informationen finden Sie unter Parse. Parse ist genau genommen nur ein eingebundener Load(XmlReader)-Aufruf, der intern einen StringReader einschließt.
Speichern
Verschiedene Überladungen von Save implementieren den Speicherpfad. Alle Save-Methoden verwenden ein Objektdiagramm als Eingabe und erstellen die Ausgabe als Stream, Datei oder XmlWriter-/TextWriter-Instanz.
Es wird davon ausgegangen, dass das Eingabeobjekt das Stammobjekt einer Objektdarstellung ist. Dies könnte der einzelne Stamm eines Geschäftsobjekts sein, der Stamm einer Objektstruktur für eine Seite in einem Benutzeroberflächenszenario, die Bearbeitungsoberfläche in einem Entwurfstool oder andere Stammobjektkonzepte, die für Szenarios geeignet sind.
In vielen Szenarios bezieht sich die Objektstruktur, die Sie speichern, auf einen ursprünglichen Vorgang, der XAML mit Load oder mit einer anderen, von einem Framework/Anwendungsmodell implementierten API geladen hat. Unter Umständen werden Unterschiede in der Objektstruktur erfasst. Diese hängen mit Zustandsänderungen, mit Änderungen, bei denen die Anwendung Laufzeiteinstellungen von einem Benutzer erfasst hat, geänderter XAML, da die Anwendung eine XAML-Entwurfsoberfläche usw., zusammen. Mit oder ohne Änderungen wird das Konzept zum Laden von XAML aus dem Markup und dem anschließenden erneuten Speichern und Vergleichen der zwei XAML-Markupformen manchmal als Roundtripdarstellung der XAML bezeichnet.
Die Herausforderung beim Speichern und Serialisieren eines komplexen Objekts in Markupform besteht darin, eine Balance zwischen vollständiger Darstellung ohne Informationsverlust und übermäßiger Ausführlichkeit zu erreichen, durch die die Lesbarkeit des XAML beeinträchtigt wird. Darüber hinaus könnten andere Kunden für XAML über andere Definitionen oder Erwartungen im Hinblick darauf verfügen, wie dieses Gleichgewicht festgelegt werden sollte. Die Save-APIs stellen eine Definition dieses Gleichgewichts dar. Die Save-APIs verwenden den verfügbaren XAML-Schemakontext und die CLR-basierten Standardeigenschaften von XamlType, XamlMember sowie andere XAML-systeminterne und XAML-Typsystemkonzepte, um zu bestimmen, wo bestimmte XAML-Knotenstreamkonstrukte beim erneuten Speichern im Markup optimiert werden können. Beispiel: XamlServices-Speicherpfade können den CLR-basierten XAML-Standardschemakontext verwenden, um XamlType für Objekte aufzulösen, eine XamlType.ContentProperty bestimmen und anschließend Eigenschaftselementtags weglassen, wenn sie die Eigenschaft in den XAML-Inhalt des Objekts schreiben.
Transform
Transform konvertiert oder transformiert XAML, indem sie einen Ladepfad und einen Speicherpfad als einzelnen Vorgang verknüpft. Ein anderer Schemakontext oder ein anderes Unterstützungstypsystem kann für XamlReader und XamlWriter verwendet werden. Dies wirkt sich darauf aus, wie das resultierende XAML transformiert wird, und funktioniert gut für umfassende Transformationsvorgänge.
Für Vorgänge, bei denen jeder Knoten in einem XAML-Knotenstream untersucht wird, wird Transform in der Regel nicht verwendet. Stattdessen müssen Sie eigene Ladepfad-/Speicherpfadvorgänge definieren und eigene Logik verwenden. Verwenden Sie in einem der Pfade ein XAML Reader/XAML-Writer-Paar um Ihre eigene Knotenschleife. Laden Sie z. B. die ursprüngliche XAML mit XamlXmlReader, und springen Sie mit aufeinander folgenden Read-Aufrufen in die Knoten. Durch das Vorgehen auf XAML-Knotenstreamebene können Sie jetzt einzelne Knoten (Typen, Member, andere Knoten) anpassen, um eine Transformation anzuwenden oder die Knoten unverändert beibehalten. Anschließend senden Sie den Knoten an die relevante Write-API eines XamlObjectWriter und schreiben das Objekt aus. Weitere Informationen finden Sie unter Grundlagen zu XAML-Knotenstreamstrukturen und -konzepten.