Serialiseringsbegränsningar för XamlWriter.Save

API-Save kan användas för att serialisera innehållet i ett WPF-program (Windows Presentation Foundation) som en XAML-fil (Extensible Application Markup Language). Det finns dock några viktiga begränsningar i exakt vad som serialiseras. Dessa begränsningar och vissa allmänna överväganden beskrivs i det här avsnittet.

Körningstid, inte Design-Time representation

Den grundläggande filosofin för vad som serialiseras genom ett anrop till Save är att resultatet vid körtid blir en representation av det objekt som serialiseras. Många designtidsegenskaper för den ursprungliga XAML-filen kanske redan är optimerade eller förlorade när XAML läses in som minnesinterna objekt och bevaras inte när du anropar Save för att serialisera. Det serialiserade resultatet är en effektiv representation av programmets konstruerade logiska träd, men inte nödvändigtvis av den ursprungliga XAML som producerade det. Dessa problem gör det extremt svårt att använda Save serialisering som en del av en omfattande XAML-designyta.

Serialisering är Self-Contained

Serialiserade utdata från Save är fristående. allt som serialiseras finns på en enda XAML-sida, med ett enda rotelement och inga externa referenser förutom URI:er. Om sidan till exempel refererade till resurser från programresurser visas dessa som om de var en komponent på sidan som serialiserades.

Tilläggsreferenser är derefererade

Vanliga referenser till objekt som skapats av olika markup extensionsformat, till exempel StaticResource eller Binding, kommer att avrefereras av serialiseringsprocessen. Dessa var redan derefererade vid den tidpunkt då minnesinterna objekt skapades av programkörningen, och Save logiken går inte tillbaka till den ursprungliga XAML för att återställa sådana referenser till serialiserade utdata. Detta kan frysa alla databundna värden eller resurser som hämtats till det värde som senast användes av körningsrepresentationen, med endast begränsad eller indirekt möjlighet att skilja ett sådant värde från andra värden som angetts lokalt. Bilder serialiseras också som objektreferenser till bilder som de finns i projektet, i stället för som ursprungliga källreferenser, och förlorar det filnamn eller den URI som ursprungligen refererades. Även resurser som deklareras på samma sida visas serialiserade till den punkt där de refererades, i stället för att bevaras som en nyckel i en resurssamling.

Händelsehantering bevaras inte

När händelsehanterare som läggs till via XAML serialiseras bevaras de inte. XAML utan bakomliggande kod (och även utan den relaterade x:Code-mekanismen) har inget sätt att serialisera körningsprocedurlogik. Eftersom serialiseringen är fristående och begränsad till det logiska trädet finns det ingen möjlighet att lagra händelsehanterarna. Därför tas händelsehanterarattribut, både själva attributet och strängvärdet som namnger hanteraren, bort från XAML-utdata.

Realistiska scenarier för användning av XAMLWriter.Save

Även om de begränsningar som anges här är ganska stora finns det fortfarande flera lämpliga scenarier för att använda Save för serialisering.

• Vektor eller grafiska utdata: Utdata från det renderade området kan användas för att återskapa samma vektor eller grafik när den läses in igen.

• RTF- och flödande dokument: Text och all elementformatering samt innehållande av element i dessa bevaras i utdata. Detta kan vara användbart för mekanismer som efterliknar en urklippsfunktion.

• Bevara affärsobjektdata: Om du har lagrat data i anpassade element, till exempel XML-data, så länge dina affärsobjekt följer grundläggande XAML-regler som att tillhandahålla anpassade konstruktorer och konvertering för egenskapsvärden med referens, kan dessa affärsobjekt vidmakthållas genom serialisering.