本文比較 LINQ to XML 與下列 XML 技術： XmlReader、XSLT、MSXML 和 XmlLite。 此資訊可協助您決定要使用的技術。
如需 LINQ to XML 與檔案物件模型 （DOM） 的比較，請參閱 LINQ to XML 與 DOM。
LINQ to XML 與 XmlReader
XmlReader 是快速、向前專用、非快取剖析器。
LINQ to XML 是建構在 XmlReader 之上，並且它們緊密整合。 不過，您也可以直接使用 XmlReader 。
例如，假設您建置的 Web 服務每秒會剖析數百份 XML 檔，而且檔具有相同的結構，這表示您只需要撰寫一個程式代碼實作來剖析 XML。 在此情況下，您可能想要直接使用 XmlReader 。
相反地，如果您要建置可剖析許多較小 XML 檔的系統，而且每個檔都不同，您會想要利用 LINQ to XML 所提供的生產力改進。
LINQ to XML 與 XSLT
LINQ to XML 和 XSLT 都提供廣泛的 XML 檔轉換功能。 XSLT 是以規則為基礎的宣告式方法。 進階 XSLT 程式設計人員會以強調無狀態方法的功能程式設計樣式撰寫 XSLT。 轉換可以使用實作沒有副作用的純函式來撰寫。 此以規則為基礎的或功能方法對許多開發人員來說並不熟悉，而且學習可能很困難且耗時。
XSLT 可以是可產生高效能應用程式的生產力系統。 例如，某些大型 Web 公司會使用 XSLT 作為從不同資料存放區提取之 XML 產生 HTML 的方式。 Managed XSLT 引擎會將 XSLT 編譯為 Common Language Runtime （CLR） 程式代碼，並在某些案例中執行效能比原生 XSLT 引擎更好。
不過，XSLT 不會利用許多開發人員擁有的 C# 和 Visual Basic 知識。 它需要開發人員以不同且複雜的程式設計語言撰寫程式代碼。 使用 C# （或 Visual Basic） 和 XSLT 等兩個非整合開發系統，會導致較難開發和維護的軟體系統。
在熟悉使用 LINQ to XML 查詢運算式之後，LINQ to XML 轉換是一種易於使用的強大技術。 基本上，您可以使用功能建構、從各種來源提取數據、以動態方式建構 XElement 物件，以及將整個組合成新的 XML 樹狀結構，以形成 XML 檔。 轉換可以產生全新的檔。 在 LINQ to XML 中建構轉換相當簡單且直覺，而且產生的程式代碼是可讀取的。 這樣可降低開發和維護成本。
LINQ to XML 並非用來取代 XSLT。 XSLT 仍然是複雜且以檔為中心的 XML 轉換選擇的工具，特別是當文件的結構未妥善定義時。
XSLT 的優點是成為萬維網聯合會 （W3C） 標準。 如果您有只使用標準技術的需求，XSLT 可能更合適。
XSLT 是 XML，這就是為什麼它可以以程式方式進行操作。
LINQ to XML 與 MSXML
MSXML 是處理 windows Microsoft 隨附之 XML 的 COM 型技術。 MSXML 提供 DOM 的原生實作，並支援 XPath 和 XSLT。 它也包含 SAX2 非快取、事件型剖析器。
MSXML 在大部分情況下都表現良好，在大部分情況下都是安全的，而且可以在瀏覽器中存取，以在AJAX 樣式應用程式中執行用戶端 XML 處理。 MSXML 可用於支援 COM 的任何程式設計語言，包括C++、JavaScript 和 Visual Basic 6.0。
不建議在基於 CLR 的管理程式碼中使用 MSXML。
LINQ to XML 與 XmlLite
XmlLite 是一種非快取、只向前的拉式解析器。 開發人員主要使用 XmlLite 搭配C++。 不建議開發人員將 XmlLite 與受控代碼一起使用。
XmlLite 的主要優點是它是一個輕量型、快速的 XML 剖析器，在大部分情況下都是安全的。 其威脅表面區域很小。 如果您必須剖析不受信任的檔，而且想要防止攻擊，例如阻斷服務或公開數據，XmlLite 可能是一個很好的選項。
XmlLite 未與 Language-Integrated Query 整合（LINQ）。 它無法提升程式設計人員的生產力，而提升生產力正是 LINQ 背後的推動力。
