XAMLServices 類別和基本 XAML 的讀取或寫入
XamlServices 是 .NET Framework XAML 服務所提供的一個類別，可用來應付不需要特地存取 XAML 節點資料流或 XAML 型別系統資訊 (這些資訊是從 XAML 節點取得) 的 XAML 情境。 XamlServices API 可概括說明如下：Load 或 Parse 用以支援 XAML 載入路徑、Save 用以支援 XAML 儲存路徑，Transform 則提供結合載入路徑和儲存路徑的技術。 Transform 可用以在 XAML 結構描述之間轉換。 本主題會摘要說明這些 API 分類，並說明特定方法多載之間的差異。
這個主題包含下列章節。
- Load
- Parse
- Save
- Transform
- 相關主題
Load
Load 有多種多載會實作載入路徑的完整邏輯。 載入路徑會使用某種形式的 XAML，然後輸出 XAML 節點資料流。 這些載入路徑大多會使用編碼 XML 文字檔形式的 XAML。 但您也可以載入一般資料流，或是載入已包含在其他 XamlReader 實作中的預先載入 XAML 原始碼。
就大部分的情節而言，最簡單的多載是 Load(String)。 多載具有 fileName 參數，該參數就是要載入的 XAML 所在之文字檔的名稱。 這適用於先前已將狀態或資料序列化至本機電腦上的應用程式情節 (例如完全信任應用程式)。 在您的架構中，如果您要定義應用程式模型，並且要載入其中一個標準檔案 (這個標準檔案定義應用程式行為、起始 UI 或是由架構所定義的其他會使用 XAML 的功能)，則也很適合使用這個簽章。
Load(Stream) 具有類似的情節。 如果您要讓使用者選擇要載入的檔案，則此多載也會很有用，因為 Stream 經常是其他可存取檔案系統的 System.IO API 的輸出。 或者，您也可以透過非同步下載或其他同樣能夠提供資料流的網路技術，來存取 XAML 原始碼。 (從資料流或使用者選取的原始碼載入可能會有安全性隱憂。 如需詳細資訊，請參閱 XAML 安全性考量)。
Load(TextReader) 和 Load(XmlReader) 這兩種多載均需倚賴舊版 .NET Framework 的讀取器格式。 若要使用這些多載，您應已建立讀取器執行個體，並已使用該讀取器執行個體的 Create API 載入使用相關格式 (文字或 XML) 的 XAML。 即使您已移動其他讀取器中的記錄指標，或是以這些讀取器執行其他作業，也沒有關係。 從 Load 執行的載入路徑邏輯，一律會從根位置往下處理整個 XAML 輸入。 這些多載的情節可能包括：
設計可讓您從現有的 XML 特定文字編輯器提供簡易 XAML 編輯功能的介面。
核心 System.IO 的衍生情節，此時您會使用專用讀取器開啟檔案或資料流。 您的邏輯在嘗試將內容載入為 XAML 之前，會先對其執行初步的檢查或處理。
您可以載入檔案或資料流，也可以載入 XmlReader、TextReader 或 XamlReader，藉由與該讀取器的 API 一起載入以包裝您的 XAML 輸入。
就內部而言，前述每種多載最終都會是 Load(XmlReader)，其中傳遞的 XmlReader 會用以建立新的 XamlXmlReader。
更進階情節適用的 Load 簽章是 Load(XamlReader)。 這個簽章可運用在下列其中一種情況：
您已自行定義 XamlReader 的實作。
您必須指定不同於預設值的 XamlReader 設定。
下列任何一項的設定皆屬於非預設設定：AllowProtectedMembersOnRoot、BaseUri、IgnoreUidsOnPropertyElements、LocalAssembly、ValuesMustBeString。 XamlServices 的預設讀取器為 XamlXmlReader。 如果您提供了自己的 XamlXmlReader 和設定，則應為下列屬性設定非預設 XamlXmlReaderSettings 設定：CloseInput、SkipXmlCompatibilityProcessing、XmlLang、XmlSpacePreserve。
Parse
Parse 類似 Load，因為它是一個會從 XAML 輸入建立 XAML 節點資料流的載入路徑 API。 但在這個案例中，XAML 輸入會直接以字串的形式提供，其中包含要載入的所有 XAML。 Parse 是較適用於應用程式情節的輕量型方法，對架構情節而言較不適用。 如需詳細資訊，請參閱 Parse。 Parse 實際上只是內含 StringReader 的包裝 Load(XmlReader) 呼叫。
Save
Save 有多種多載會實作儲存路徑。 所有 Save 方法都會接受物件圖形做為輸入，然後產生資料流、檔案或 XmlWriter/TextWriter 執行個體等形式的輸出。
輸入物件應為某個物件表示的根物件。 這可以是商務物件的單一根、UI 情節中頁面的物件樹狀結構的根、設計工具中的工作編輯介面，或是其他情節中的適當根物件概念。
在許多情節中，您所儲存的物件樹狀結構，都與用來載入 XAML 的原始作業 (不論是由 Load 或是架構/應用程式模型所實作的其他 API 執行) 有關。 物件樹狀結構中可能會出現差異，其原因包括狀態變更、應用程式擷取到使用者在執行階段做出的設定變更、由於應用程式是 XAML 設計介面而影響的 XAML 變更等等。 無論是否有所變更，從標記載入 XAML 再儲存 XAML，然後比較兩個 XAML 標記格式的這個概念，有時會被視為 XAML 的反覆存取表示。
儲存和序列化標記形式之複雜物件集的困難之處，在於如何能夠完整表示而不漏失資訊，同時又不致過於繁瑣而使 XAML 不易閱讀。 再者，不同的 XAML 客戶對於如何拿捏此一平衡，也有不同的定義或期望。 Save API 就是此平衡的其中一種定義。 Save API 會使用可用的 XAML 結構描述內容以及 XamlType、XamlMember 和其他 XAML 本質與 XAML 型別系統概念的預設 CLR 型特性，來判斷特定的 XAML 節點資料流建構在重新儲存成標記時可進行最佳化的位置。 例如，XamlServices 儲存路徑可以使用 CLR 型預設 XAML 結構描述內容來解析物件的 XamlType、判斷 XamlType.ContentProperty，接著在將屬性寫入至該物件的 XAML 內容時省略屬性項目標記。
Transform
Transform 會藉由將載入路徑和儲存路徑連結成單一作業，以轉換 XAML。 XamlReader 和 XamlWriter 則可能會使用不同的結構描述內容或備份型別系統，而這正是影響 XAML 轉換結果的因素。 這個項目適用於各種各樣的轉換作業。
如果作業需要檢查 XAML 節點資料流中的每個節點，您通常不會使用 Transform。 您需要定義自己的載入路徑-儲存路徑作業序列，並插入自己的邏輯。 請在其中一個路徑中，在您自己的節點迴圈四處使用 XAML 讀取器/XAML 寫入器配對。 例如，請使用 XamlXmlReader 載入初始 XAML，再以後續的 Read 呼叫逐步執行至各節點。 在 XAML 節點資料流層級上運作時，您可以調整個別的節點 (型別、成員、其他節點) 以套用轉換，或讓節點保持原狀。 接著，您會將節點繼續傳送至 XamlObjectWriter 的相關 Write API，然後寫出物件。 如需詳細資訊，請參閱認識 XAML 節點資料流結構和概念。