為 Web 開發支援 XML 的資料解決方案

為 Web 開發支援 XML 的資料解決方案發布日期： 4/1/2004 | 更新日期： 4/1/2004

Scott Howlett 和 Darryl Jennings 本文假設讀者熟悉 XML、ASP 和 ADO。下載本文提供的代碼：SQLXML.exe (516KB)

摘要 將 XML 用於資料訪問使您可以將資料從表示形式中分離出來，並可以提高可重用性、可擴充性和人工的分配。XML 還有一個簡化的資料模型，可以使測試更容易。本文提供並比較了五種資料存取方法，這些方法使用各種技術，包括 ASP 和 ADO、XSLT 以及 DirectXML。構建解決方案後，根據它們的速度和效率對它們進行比較。

假設您正在設計資料驅動的 Internet 應用程式。您要從資料庫擷取資料，以便在 Web 上進行展示。另外，您想要確保此解決方案架構良好，但又不將效能作為主要考慮事項。您非常希望用於下遊方向（從資料庫到瀏覽器）的解決方案很好地向上遊方向（從瀏覽器到資料庫）擴充。

本文是 MSDN_ Magazine 2000 年 9 月一期中 "Beyond ASP:XML and XSL-based Solutions Simplify Your Data Presentation Layer" 一文的後續內容。在討論為上述方案實現的各種解決方案之前，我們將首先快速回顧一下那篇文章，然後闡明一些根據我們前 10 個月以來收到的大量反饋的主題。

接下來，將概述 SQL Server 2000 對 XML 的支援，焦點集中在使用 XSD 映射架構的模板和更新圖上。然後，將在實踐中介紹實現這些想法的應用程式範例。基本上，使用五種不同的方法產生同一應用程式範例，每次使用 ASP、ADO、XML、XSLT、SQL Server 2000 和 .NET 技術的不同組合。最後，還包含了基準測試編號,以解決開發人員使用基於 XML 的結構時有關效能和延展性方面所關心的問題。

回顧

過去，我們將 XML 和 XSL 用於所有類型的解決方案，從大型公司專屬應用程式程式一直到五天或十天的小項目。我們發現其中的大多數 XML 資源實際上集中在作為企業技術的 XML 上，因此大多數網站仍在使用傳統 ASP 方法進行構建，此方法自從第一次從早期的 Microsoft_ Internet Information Server (IIS) 3.0 中引入以來基本上未做任何更改。

從 "Beyond ASP" 文章發表的那一年之後，情況有了很大變化。最值得注意的是，在 2000 年 10 月發布了 MSXML 3.0（支援 W3C 標準 XSLT），接下來發布了 .NET，然後發布了 SQL Server 2000，而且很快又出現了兩個增強其 XML 功能的 Web 發佈版本。簡而言之，這些新技術增強了用於幾乎所有基於 Internet 的應用程式的以 XML 為中心的方法。事實上，為了最佳化對基於 Microsoft .NET 的伺服器的開發，必須將 XML 作為結構的中心予以考慮。

以 XML 為中心的 Internet 開發方法已經成為主流。同時，資料庫的介面正從 SQL 向雙向 XML 轉變，因此可能提供很多新的強大功能。在這裡，我們將主要討論新興技術如何將此設計概念變為現實。

另一個需要注意之處—我們在範例程式碼上花費了大量時間（甚至提供了協助設定內容的讀我檔案），所以請對它進行嘗試。在本文頂部的連結中可以找到本文的所有代碼。

使用 XML 的九個原因

XML 促進了表示形式與資料的分離，提高了可重用性、可擴充性和人工的分配。另外，它有一個簡化的資料模型，允許一個位置有一個事務，並協助簡化測試。還因為 XML 可與舊式系統整合在一起（將來一定繼續發展的趨勢）而受到越來越多的歡迎。

在這裡，我們將集中討論其中的三點：

•	1. 人工的分配。不同的小組成員有不同的技能，結構設計良好的解決方案可以充分發揮每個小組成員的技能水平。要有效地執行此任務，必須從前端開發人員處抽象出關係資料模型。
•	2. 一個位置一個事務。XML 在單一可移植實體中提供完整事務和複雜資料集。此可移植資料容器是對記錄集或其他專用資料格式的跨越。
•	3. 展望未來。Microsoft 已經將 XML 採納為 .NET 平台的關鍵技術之一，我們將在檢驗 .NET 企業級伺服器時討論 .NET 平台。

將根據這三個標準對五個應用程式範例中的每一個進行測量。

 

XML 和 XSLT

認識到下面這一點很重要：當使用 XSLT 時，沒有交叉瀏覽器問題—如果用戶端不支援 XSLT，始終可以在伺服器上執行轉換。另外，您會發現 XSLT 產生的 HTML 比您通過其他方法獲得的 HTML 更符合 HTML 標準。

您還會發現，在產生複雜的 HTML 頁面方面，XSLT 的能力與過程代碼一樣強。另外，對於無數例外中的那些內容，可以始終採取調出到指令碼的方法。作為 XSLT 能力的樣本，可將 EDI 文檔轉換為 XML 的 BizTalk Mapper 使用底層的 XSLT。熟悉它之後，XSLT 會比帶有嵌入 HTML 的過程代碼更模組化（因而更可維護）。

使用 XML，不會有磁碟輸入/輸出問題。由於所有 XML 文檔載入到記憶體中，使用 XML/XSLT 方法不會比其他方法產生更多的磁碟 I/O 操作。開發人員已明確關注使用指令碼代碼（而不是已編譯的 COM 物件）時的效能。坦率地講，我們使用指令碼產生應用程式範例是因為它們更便於使用者在他們自己的系統上下載、安裝和運行。在任何事件中，指令碼代碼與 Windows_ 2000 上基於 Visual Basic_ 的 COM 代碼之間都會有可忽略的效能差異。不相信我們嗎？請參閱 Architecture Decisions for Dynamic Web Applications:Performance, Scalability, and Reliability。

開發人員還關注使用 RecordsetToXMLDoc 函數時的效能，此函數通過在記錄中進行迴圈以將 ADO 記錄集轉換為 XML 文檔來產生 XML。為什麼不應該使用 ADODB.Recordset.Save adPersistXML（它產生二維 XML 結構）？很顯然，它的優點只比直接使用記錄集多一點，況且您不能對產生的 XML 結構進行控制。XML 的強大功能在於它可為任意深的分層資料建模的能力—將您自己限制在二維階層（使用 adPersistXML 導致的結果）會極大降低 XML 的功能。

另一個效能考慮集中在 XML 解決方案公開的執行層數量上。如果允許，通過將記錄集手動轉換為 XML，可以添加另一層。但是，軟體是完全抽象的，這通常意味著引入另一層。您很快會看到，使用在 SQL Server 2000 中引入的功能，可以獲得所有抽象好處（不用引入另一層），並且效能會同時獲得很大提高。

像任何新技術一樣，需要花一些時間熟悉 XML 和 XSLT。應該記住，遲早您必須學會 XML—只要隨意掃一眼 BizTalk 和 .NET，您便會在某一處看到 Microsoft 已經採用了 XML。圖 1 是您需要瞭解的一些術語的方便參考指南。

 

SQL Server 2000 的 XML 功能

許多開發人員指出（事實上確實如此）從屬記錄集到 XML 的轉換會引入另一個執行層。即使這樣，我們仍會在 XML/XSLT 設計模式中發現許多好處。SQL Server 2000 附帶了本機 XML 支援，而且 SQL Server 2000 Web Release 2 Beta 1 (WR2b1) 甚至還添加了更多的基於 XML 的功能，從而避免了層的問題。現在，可以獲得 XML 的所有好處，不用引入額外的執行層，進而避免了因引入執行層而產生的複雜性。

Microsoft 的開發人員在可通過 HTTP 訪問 SQL Server 2000 的 XML 功能方面做了很多工作。此存取方法需要在伺服器上配置虛擬目錄，有關詳細資料，將在應用程式範例的安裝說明中進行解釋。從 Web Release 2 Beta 1 起，還可以通過使用 ADO 命令、流和連線物件，以編程方式使用 SQL Server 2000 XML 功能。為了更好地瞭解如何同時使用 HTTP 和編程存取方法以及它們的執行方式，我們使用它們開發了第三方應用程式範例。出乎我們的意料，基於 HTTP 的訪問遠比通過 ADO 的編程執行快（請參閱本文結尾處關於效能的一節）。

有兩種不同的方法可用來根據 SQL 資料庫的內容產生 XML 視圖。您將會看到，產生的 XML 可以基於一個或多個表，而且可以為任意深。第一個方法使用 SQL Server 2000 擴充的 SELECT 語句文法，第二個方法利用對 XPath 查詢和映射架構的支援。SQL 擴充功能可以與模板一起使用，也可以不與其一起使用，並且不需要映射架構。相反，XPath 查詢必須在模板內使用，而且此模板必須指定映射架構。

 

SQL 查詢擴充功能

SELECT 語句的文法已經進行了擴充，以支援使用新的 FOR XML 子句直接從 SQL Server 2000 檢索 XML 文檔。FOR XML 子句有三個使用模式，每一個模式都允許對其產生的 XML 文檔的外觀進行不同程度的控制。這些模式為 Raw、Auto 和 Explicit。對於如何使用這些方法的完整解釋已超出了本文範圍，但 SQL Server 2000 文檔中給出了很好的說明。SQL 查詢擴充功能的一個很大的限制是它們不利於使用更新圖（更新圖需要映射架構）。

Raw 模式（用於 XML RAW）產生一個 XML 文檔，此文檔與 ADODB.Recordset.Save adPersistXML 方法產生的文檔類似（有關此方法的更多資訊，請參閱 ADO 文檔）。這意味著產生的 XML 文檔將有一個較淺的階層，並且只會像傳統記錄集那樣工作，而不能利用使用 XML 時可用的任意複雜的樹結構。

Auto 模式（用於 XML AUTO）能夠根據表的數量和順序以及 SELECT 語句的 FROM 子句中使用的聯結策略，自動產生 XML 文檔。各種聯結風格的創新使用有助於產生許多簡單的 XML 文檔結構，但是當嘗試發布帶有複雜結構的文檔時其局限性會很快暴露出來。

Explicit 模式可用於對產生的 XML 文檔的效能進行完全的控制，因此使用起來更複雜一些。基本上，您獲得了對 XML 文檔的完全控制，但同時失去了映射方案的好處。

請注意，FOR XML 子句有一個稱為 XMLData 的選項，如果指定了此選項，則會包括一個自動產生的帶有 XML 視圖的 XDR 方案內聯，但它不是映射方案。

 

SQL 模板

如上所述，通過指定使用了 SQL 查詢擴充 FOR XML 的SELECT 語句，或者通過指定映射方案和 XPath 查詢，可以使用模板。我們認為將模板與 XSD 映射方案和 XPath 查詢一起使用是從 SQL Server 2000 直接擷取基於 XML 的資料的最強大機制。

您可以回想一下，如果 XSD 方案包括 SQL Server 2000 需要的所有必需的批註，以便處理從關係資料存放區到 XML 視圖的映射，則它是映射方案。特別地，必須使用 sql:relationship 標記來明確定義外鍵關係。這些關係必須包括在 xsd:annotation 標記中，以便使映射方案符合 XSD。圖 2 是這些批註的樣本。

圖 3 顯示了用於應用程式範例的 XSD 映射方案，而不顯示圖 2 中的批註以便節省空間的。（如果還不熟悉 XSD 方案，可以參閱 http://www.w3.org/TR/xmlschema-0。）注意關係資料存放區中的表和列如何使用屬性對應到 XML 元素：sql:relation 映射表，sql:key-fields 映射主鍵，sql:field 映射列，sql:relationship 映射鍵關係。

由於許多原因，SQL 擴充功能首選使用映射方案和模板。例如，無論如何，您都需要映射方案以使用更新圖，且複雜映射方案比 FOR XML Explicit 等效方案更容易編寫。另外，使用 SQL 查詢擴充功能需要您編寫 SELECT 語句，而映射方案的添加則不需要。您還會發現映射方案對 .NET 和 BizTalk 方案都非常有用。最後，XML 最佳實施規定了方案的使用。

另外，XSD 首選層級高於 XDR，因為 XSD 是 W3C 標準。此模板產生使用 XSD 映射方案的資料的 XML 視圖。

<persons xmlns:sql="urn:schemas=microsoft=com:xml=sql"> <sql:xpath-query mapping-schema=:./persons.xsd:> person </sql:xpath-query> </persons> Visual Studio .NET 設計器將為您顯示 XSD 方案 (sqlxml/persons.xsd)。前面的模板還產生了 4 所示的 XML 資料。

 

SQL 更新圖

如果對通過符合 XSD 映射方案的可自訂形式從 SQL 資料庫提取資料並不感興趣，請記住，您還可以使用更新圖。更新圖使您可以提供要映射回資料庫的符合方案的 XML 文檔，而不是編寫自己的分解代碼和插入代碼。

在第二個 SQL Server 2000 Web 發佈版本中包括了對更新圖的支援。它們使使用者可以根據 XML 文檔及其相應映射方案的內容插入、更新和刪除關聯式資料庫資訊。這使 SQL Server 2000 可以成為雙向 XML 庫！使用者現在可以用 XML 文檔的形式請求資訊，變更，添加和刪除資訊，然後將它以 XML 格式發回，讓它在關聯式資料庫中正確映射和儲存。

更新圖很容易使用（雖然此時錯誤訊息通常很不明確）。在更新圖中，所有工作都在 <sync> 塊之間完成。可以包括任意數量的 <sync> 塊，在它們中所做的所有更改都是事務性的。每個事務可以包含任意數量的 before 塊和 after 塊。

這些塊的功能非常直觀。<before> 塊包含現有 XML 視圖的一部分，<after>塊是當變更時您想要這部分視圖所呈現出的外觀。根據 <before> 與 <after> 塊之間的差異以及您提供的映射方案，為您完成所有插入、更新和刪除工作。（有關更新圖的使用，請參閱隨第二個 Web 發佈版本提供的 "XML for SQL" 文檔）。請注意，更新圖可以影響多個行和多個表。圖 5 是在 pubs 資料庫中修改資料的更新圖的樣本。

更新圖如何處理對資料庫的並發訪問，即避免使用者 B 的更新覆蓋使用者 A 的更新？答案在於更新圖對樂觀鎖定策略的靈活使用。基本上，SQL Server 2000 會將更新圖中的 <before> 塊的內容與資料庫中已有的內容進行比較。如果資料不同，由於檢測到樂觀鎖定，此操作將不繼續。

您在 <before> 塊中包含的資訊越多，衝突檢測將越嚴格。通過只包括鍵欄位，將始終應用您的更新，除非鍵欄位不再存在。如果您下載本文的範例程式碼，則會發現樣本更新圖和 ADO 執行代碼，該執行代碼只包括 <before> 塊中的主鍵。

所以，現在我們有一個機制，使用模板和 XSD 映射方案直接從 SQL Server 2000 擷取 XML。我們還有一個機制，使用更新圖和相同的 XSD 映射方案將 XML 直接擷取到 SQL Server 2000 中。所有這些操作甚至連一行 SQL 都不用寫入。很酷。

 

應用程式範例

下一步，讓我們直接跳到應用程式範例，以便您可以瞭解正在產生的內容。我們決定從 pubs 資料庫展示作者及其相關書籍的顯示。 圖 6 顯示了資料的產生視圖。資料的視圖有些複雜，它包括某種伺服器產生的 DHTML，該 DHTML 允許根據需要展開或摺疊每個作者的書籍。

 

圖 6 DHTML 唯讀視圖

我們以 7 所示的五個不同方法產生樣本頁面。將在下面的幾節中描述這些解決方案/應用程式範例中的每一個。

 

解決方案 1

使用 ASP 和 ADO 產生此頁面時所需的代碼（圖 8 中給出了概念性顯示）看起來應該非常熟悉。

 

可以在 straightasp.asp 中找到完整的代碼清單， 圖 9 顯示了所需代碼的一部分。很明顯，資料存取碼無奈地與表示形式代碼纏繞在一起。圖 10 顯示此解決方案對各種標準排列得多麼出色。

 

解決方案 2

在稱為解決方案 2（圖 11 中給出了概念性定義）的方法中，我們像解決方案 1 中一樣對資料庫進行了相同的調用，但在執行時並未產生 HTML，而是得到了一個函數調用 (GetXMLFromDB) 中的所有資料，然後應用了 XSLT 樣式表。在此情況下，資料已經從完全從任何錶示形式格式刪除。 圖 12 顯示了從資料庫產生 XML 所必需的代碼。

 

圖 11 #2

2000 年 11 月的文章中包含了 RecordsetToXMLDoc 函數。可以在代碼下載中的 xml/xmlutil2.asp 檔案中找到此函數的更新版本。擁有資料後，進行轉換非常簡單。圖 13 顯示了執行轉換所需的代碼。

您會注意到，基於查詢字串中的值，有三個不同的已執行轉換。第一個使用 defaultss.xsl（它顯示了原始 XML）進行轉換。TransformXML 與 TransformXML2 之間的區別在於 TransformXML2 使用在應用程式變數中儲存的緩衝的樣式表（通過 XSLTemplate 對象）。如果您想要使用 XSLTemplate，從閱讀文章 "Inside MSXML3 Performance" 入手進行學習是非常理想的，該文還討論了此方法如何改善效能。在 inc/xmlutil2.asp（在下載中）中，可以找到函數 TransformXML 和 TransformXML2 的代碼。圖 14 中總結瞭解決方案 2。

 

解決方案 3

解決方案 3（圖 15 中給出了概念性顯示）看起來與最後一個解決方案很相似，但我們使用 SQL Server 2000 的 XML 功能，而並不手工產生 XML。“SQL Server 2000 的 XML 功能”一節詳細解釋了此過程，但我們已做的是使用 XSD 方案建立資料的視圖。使用此視圖，我們指定了 XPath 運算式以提取想要的資料。 圖 16 顯示了如何使用 SQL Server 2000 WR2b1 附帶的 SQLXMLOLEDB 提供者以編程方式完成此操作。

 

圖 15 #3

可以使用 ADO（通過 SQXMLOLEDB 提供者）或使用 SQL Server 2000 基於 HTTP 的訪問機制以編程方式執行 SQL 模板。此解決方案同時展示了使用同一模板的兩個執行選項，以方便對這兩者進行比較。基於 HTTP 的訪問並不比程式簡單，但它速度更快（請參閱本文結尾關於效能的一節）。

ShowAuthorsView 的代碼與解決方案 2 中的代碼幾乎完全相同，但是添加了對基於 HTTP 的資料訪問的支援。另外，還添加了對要在模板中使用的不同 XPath 運算式的支援。圖 17 顯示應用了 XPath 篩選器（此篩選器只能顯示協定值為零的作者）的應用程式範例。

 

使用 XPath 進行篩選

XPath 查詢並不始終按我們期望的方式工作（還記得測試軟體嗎？）。 這裡是當執行 XPath 查詢時找到的內容。首先，嘗試根據不是立即子級的子節點進行篩選的 XPath 運算式將失敗 (person[books/book/title_id='PS3333'])，並顯示錯誤 "Xpath:an unexpected internal error occurred"（Xpath：發生了意外內部錯誤）。其次，嘗試根據標有 sql:is-constant 的節點所包含的子級進行篩選的 XPath 運算式（例如，person[address/state='CA']）會失敗，並顯示錯誤 "The column prefix '_Q1G' does not match with a table name or alias name used in the query."（列首碼 '_Q1G' 與查詢中使用的表名或別名不匹配）。

令人期待的是，當發布 WR2b1 for SQL Server 2000 時，我們 將能夠使用大量的 XPath 運算式，例如：person[books/book/price > 10]，表示編寫書籍的所有人，書籍的銷售價格超過 10 美元；person[books/book/publisher/location/country='USA']，表示編輯書籍的所有人，書籍的出版商在美國。有關解決方案 3 的分級總結，請參閱圖 18。

 

解決方案 4

解決方案 4（圖 19 中給出了模型）與解決方案 3 的工作方式幾乎完全相同，不同之處是使用 .NET XML WebControl 來進行轉換。

 

圖 19 #4

我們在 Page_Load 方法（來自 dotnettransform.aspx.cs）中只需寫四行代碼，以載入源 XML 文檔（使用基於 SQL Server 2000 HTTP 的 XML 訪問）和樣式表。

private void Page_Load(object sender, System.EventArgs e){    // Put user code to initialize the page here    XmlDocument doc = new XmlDocument();    doc.Load("http://localhost/pubs/templates/alldata.xml");    ctlXML.Document = doc;    ctlXML.TransformSource = "xsl//authors3.xsl";}

此解決方案並不需要 inc/xmlutil.asp 中的代碼，因此，使用 .NET 執行轉換不需要 DOM 知識。 圖 20 總結瞭解決方案 4。

解決方案 5

對於解決方案 5（圖 21 給出了概述），我們曾想過使用 .NET 中的 DataGrid 產生資料檢視，以查看在不寫入任何代碼（C# 或 XSLT）的情況下可以擷取何種功能。

 

圖 21 #5

很明顯，產生與解決方案 1 到 4 的格式完全相同的資料檢視超出了本文的範圍。但是，產生作者的簡單視圖（不使用用戶端的 DHTML）確實是很簡單的練習。不用寫任何代碼，即可完成幾乎所有內容！下面是操作步驟：

•	1. 首先，使用前面提到的 XSD 架構，通過按右鍵 Project | Add Component | Data Set 建立新的資料集類。這會建立新的 XSD 檔案和 Visual Studio 自動產生的底層 CS 檔案。然後，將架構（是通過手工建立的）粘貼到 XSD 檔案中。您也可以選擇使用 XML 設計器建立 XSD 檔案。
•	2. 下一步，將資料集組件從工具框拖動到頁面上。這會開啟一個嚮導，可以在其中根據步驟 1 中建立的資料集類建立分類的資料集。您可以在圖 22 中的代碼中看到，我們調用資料集 dsPersons 和更新的 Page_Load 事件處理常式，以便使用 HTTP 從 SQL Server 2000 檢索資料。
•	3. 從那裡，我們通過按右鍵 Datagrid | Property Builder 將 DataGrid 組件從工具箱拖動到了 ASPX 頁面。我們將 dsPersons 選作資料來源，將人選作資料成員。
•	4. 接下來，我們使用了屬性產生器來選擇要顯示的列。
•	5. 從那裡，我們在屬性產生器中配置了“分頁”、“格式”和“邊框”地區。我們為 OnPageIndexChange 事件添加了事件處理常式（通過將屬性 OnPageIndexChanged="dgperson_PageIndexChanged" 添加到 .aspx 檔案中的 <asp:DataGrid> 標記）。下面的代碼來自 dotnetgrid.aspx.cs，顯示了要更改頁面的伺服器端實現。

public void dgperson_PageIndexChanged(object source,   System.Web.UI.WebControls.DataGridPageChangedEventArgs e){  dgperson.CurrentPageIndex = e.NewPageIndex;  dgperson.DataBind();}

在一天工作的結尾，產生一個資料檢視，此視圖作為產生與解決方案 1 到 4 中相似的視圖的開始點（請參閱圖 23）。.NET 遵守大量使用基於 XML 的資料集的約定。 圖 24 總結瞭解決方案 5。

圖 23 .NET DataGrid

圖 23 .NET DataGrid

 

效能

出於全面考慮，我們對五個解決方案進行了基準測試，以比較每個方法的效能。請注意，不應該將解決方案 5 與其他解決方案相比較，因為它們的資料檢視不同。

測試是使用 Homer（Microsoft 的載入測試應用程式），針對運行 Windows 2000 Server、SQL Server 2000 Web Release 2 Beta 1 和 .NET Framework Beta 2 的伺服器啟動並執行。Homer 在 Microsoft Access .mdb 檔案中儲存其配置資訊。範例程式碼 zip 檔案中已經包括了 Homer .mdb 檔案，所以您可以將它開啟，對您自己的各種配置的每一個進行基準測試。

伺服器是 Dell Dimension XPST500，550MHz，256MB 的 RAM。Homer 在單獨的工作站上運行。請特別注意圖 25 中最後一列中顯示的相對效能（與 ASP/ADO 方法比較）。

請看一看使用基於 HTTP 的資料訪問和 XSLT（解決方案 3）時令人激動的 11.1 倍的效能提高，使用基於 HTTP 的資料訪問和 .NET Transform（解決方案 4）時的效能提高几乎達九倍。雖然這些統計數字並不完全科學，但它顯示了 SQL Server 2000 和 .NET 的驚人效能。另請注意，使用過分單純化的緩衝 XSLT 機制並不始終能提高效能。

 

小結

在這個以 Internet 為中心的時代裡，XML 是否將繼續扮演重要角色已經沒有太多疑問。Microsoft 擁有完整的基於 XML 的產品，從現有發行的產品（例如，BizTalk 和 SQL Server 2000）到測試產品（例如，.NET）。對軟體架構師的挑戰是，如何在他們的應用程式中通過使用 XML 而充分利用這些伺服器產品。

使用 XSD 映射架構使基於 XML 的資料能夠流入和流出 SQL Server 2000 是非常有用的。通過使用 XSD，您將可以立即移植到 .NET，並可以使用 W3C 行業標準。同時，您還會認識到使用 XSLT 和基於 HTTP 的資料訪問時的最大效能。

有關相關文章，請參閱：

Beyond ASP:XML and XSL-based Solutions Simplify Your Data Presentation Layer

A Survey of Microsoft SQL Server 2000 XML Features有關相關文章，請參閱：

A Guide to XML and its Technologies

Inside MSXML3 Performance

Scott Howlett 和 Darryl Jennings 是 imason Inc. 的諮詢顧問，該公司是一個 Internet 諮詢公司，其業務主要是為產生“企業對企業 (B2B)”和“業務部門 (LOB)”應用程式的公司進行舊式整合。如果希望與他們聯絡，請將電子郵件發送至 scott.howlett@imason.com 和 darryl.jennings@imason.com。

摘自 MSDN Magazine 的 2002 年 1 月一期。

此雜誌可通過各地的報攤購買，也可以訂閱。

轉到原英文頁面