ADO的定義

來源:互聯網
上載者:User
ado


    在本書前7章中,已經講述了ASP的有關內容,以及ASP如何為Web網站帶來動態內容。已經見到其指令碼程式允許自訂Web頁面,使我們能夠構建功能更為強大的ASP頁面。
       現在,將研究ASP和資料的整合。雖然對用於網頁中的指令碼數量並無任何限制,但如果沒有某種形式的資料,很快就會進入一個死胡同。資料構成了Web網站的實際內容,或者指出了如何設定Web網站,因此總的說來資料是非常重要的。如果圍繞資料存放區建立Web網站,改變Web網站時只需要改變相應的資料即可。
       ActiveX資料對象(ADO)是允許使用者與資料存放區進行互動的組件。這意味著只要基於某些資料就可建立一個網頁,或一種完全互動的電子商務系統。不論哪種方式,都是ADO使我們能與資料進行通訊。我們將討論從資料存放區擷取和傳送資料的主要內容,以及得到資料後的資料處理方法。
       首先研究什麼是ADO及其所包括的組件,然後討論如何訪問資料存放區。在下一章,將進一步學習ADO更先進的一些特性,如命令、預存程序和最佳化應用程式的一些操作技巧。下一步研究Web伺服器和瀏覽器之間的互動過程,以及資料處理過程。然後研究資料存取領域中極具潛力的XML。XML是什嗎?如何使用?因為XML代表著未來發展的一種趨勢,我們將介紹微軟關於通用資料存取的構想。在這個構想中,資料不只是從資料庫中獲得的。最後,看一下標準的微軟資料庫(如Access與SQL Server)以及在其中如何使用ADO。
       本章從ADO開始,主要內容有:
       · 研究ADO如何與資料進行互動。
       · 瞭解ADO的組件。
       · 如何與資料存放區串連和建立資料集。
       · 如何處理和修改資料。
       · 如何處理ADO錯誤。

8.1 ADO的定義
       ADO是一個相當簡單的思想,一種讓你僅用一種方式去訪問資料的思想。ADO不算一個新思想,僅是採用現有的資料庫訪問技術,並將其融合而形成的一種適應現在和未來需要的新東西。適應未來的需求是一件十分重要的事。許多其他的技術,比如DAO和ODBC,在一些應用程式的開發過程中是可以接受的,然而隨著Internet的興起也出現了其自身的一些問題。
       在許多情況下,傳統的資料存取方法看上去能解決一些關於兩層客戶/伺服器系統的問題,但要求與資料之間要保持一種永久性的串連,並要提供強大的功能,比如快速響應的查詢、資料容易修改等。在Internet領域,現在必須考慮到Web無狀態性本質,和潛在的眾多可以訪問Web網站的使用者。要與資料建立永久的串連是不現實的,因此必須在設計應用程式時考慮這些因素。
       那麼,OLD DB和ADO確切地講到底是什嗎?讓我們與一些已有的資料存取技術做比較後再來回答這個問題。如果讀者曾經接觸過資料庫編程,或許比較熟悉ODBC和RDO。開放資料庫連接(ODBC)是允許訪問關聯式資料庫(比如Access和SQL Server)的API(API)。正因為是一個API,許多程式員,特別是Visual Basic領域的程式員,發現它使用起來很複雜。遠端資料物件(RDO)是位於ODBC上層的ActiveX對象,可以提供ODBC的所有功能,並且使用起來比較簡單。
       可以將OLE DB等同於ODBC,ADO等同於RDO。
       OLE DB是應用程式與資料來源互動的一種基本技術。
       這相當複雜,確實也只有C和C++程式員能夠使用。正如ADO的名字所暗示的,它是易於訪問OLE DB功能的ActiveX對象。
       你或許發現術語ActiveX與COM對象經常混用。對於ASP程式員來說它們並沒有本質上的區別,因為兩者都基於COM系統結構,只不過ActiveX是組件的一個跨平台標準,而COM是Windows專有的。
       雖然微軟已經引入了一種新的存取資料的技術,但並沒有立即取消舊的技術,ODBC工作起來仍然很有效,並同OLE DB和ADO緊密地一起工作著。事實上,ODBC並不只是微軟的產品,也受到國際組件的控制。並且由於廣泛的使用,ODBC也不會突然消亡。隱藏在OLE DB背後的思想不是摒棄現有的技術,而是不斷地改進它們。

8.1.1 OLE DB和ADO的體繫結構
       前面已經給出了OLE DB與ADO在一些主要方面的簡要解釋。圖8-1顯示了這兩項技術與應用程式和資料存放區相互關係:

       從圖8-1中可以看出整體思路。圖的頂端是應用程式(Web或常規的應用程式,這是無關緊要的),下面是提供對資料的訪問的ADO和/或OLE DB。ADO和OLE DB兩者兼有是因為OLE DB是一項基本技術。然而,OLE DB並不適用於所有語言,所以ADO位於OLE DB的上層,為那些不能直接存取OLE DB的語言(如Visual Basic和指令碼語言)提供編程介面。ADO提供了比OLE DB更容易的編程介面,因此即使那些可以直接使用OLE DB的程式設計語言,如C++或Java,也可使用ADO以簡化對資料的訪問。
       圖8-1顯示的是微軟的程式設計語言,而ADO是一個COM組件,因此可用於任何與COM相容的程式設計語言,比如Delphi或支援Active Scripting介面的指令碼語言。所以,雖然ADO與平台有關,但與開發的語言是無關的。當然,對於ASP主要使用VBScript和JScript,在組件中使用ADO時,有一些Visual Basic代碼。
       現在知道了OLE DB和ADO允許訪問資料,可是為什麼需要它們?老方法出問題了嗎?這裡有兩個主要原因:
       首先,OLE DB和ADO是用來訪問資料存放區的。注意這裡指“資料存放區”而不是“資料庫”。儘管資料庫仍舊是資料存放區最為廣泛的形式,但並不一定含有全部的資料。一些訊息系統,如Microsoft Exchange Server,也普遍地用於儲存資料。目錄服務(Directory Service)正開始在初露端倪,它們包含著有關使用者、機器等的資料;Web伺服器中存有大量的資訊。可以繼續羅列下去,很明顯需要一種能訪問所有這些不同類型資料的方法。
       其次,源於Internet應用程式的興起與Web的狀態本質。過去的訪問資料的方法主要考慮與資料存放區保持永久串連的情況下處理資料。而OLE DB和ADO正是為解決這個問題而設計的,提供中斷連線的記錄集,我們將會在後面看到有關這方面的內容。

8.1.2 消費者與提供者
       ADO系統結構圖展示了ADO是如何在應用程式和真實資料存放區之間發揮作用的。在微軟的文獻中,會看到兩個易懂的術語:消費者(Consumer)和提供者(Provider),但搞清它們的確切定義至關重要。
       提供者是提供資料的物體,消費者是使用(消耗)這些資料的物體。
       在編程中,經常會發現應用程式是資料的消費者。但提供者呢?一般是資料存放區,並且由於OLE DB被設計成用於與不同的資料存放區對話,因此對於每一個獨特類型的資料存放區都有一個OLE DB提供者。
       這種單獨提供者的思想並不新,但使編程變得容易了。編寫程式與ADO或OLE DB對話,OLE DB再與提供者對話。這意味著只需學會一套訪問資料的方法,無論資料如何儲存,在某些情況下確實可以完全不改變任何代碼而只更換提供者。這就是ADO和OLE DB真正優越的地方,為資料存放區提供了一套常用的編程介面。
       要串連到資料存放區,必須使用OLE DB提供者。提供給ADO 2.5的初始設定為:
       · Jet OLE DB 4.0:用於微軟Access資料庫。
       · DTS Packages:用於SQL Server的資料轉換服務(Data Transformation Services)。
       · Internet Publishing:用於訪問Web伺服器。
       · Indexing Services:用於索引目錄(Index Catalogs)。
       · Site Server Search:用於站台伺服器尋找目錄。
       · ODBC Drivers:用於ODBC資料來源。
       · OLAP Services:用於微軟OLAP伺服器。
       · Oracle:用於Oracle資料庫。
       · SQL Server:用於微軟SQL Server資料庫。
       · Simple Provider:用於簡單的文字檔。
       · MSDataShape:用於層次資料。
       · Microsoft Directory Services:用於Windows 2000的目錄服務。
       · DTS Flat File:用於SQL Server的資料轉換服務的一般檔案管理。
       這隻是微軟提供的初始列表,並取決於安裝在伺服器上的服務及軟體。以Oracle資料提供者為例,要求在客戶機上安裝Oracle的用戶端軟體。
       可以從別的製造商那裡獲得OLE DB提供者,用於其他資料存放區。甚至還可以編寫自己的提供者。在第11章,將示範如何編寫簡單的OLE DB提供者。
       要想知道系統安裝了哪些提供者,可以使用Data Link properties對話方塊。在本章後面,將介紹如何使用它。

8.1.3 提供者和驅動程式
       值得注意的是,OLE DB對ODBC的相容性,允許OLE DB訪問現有的ODBC資料來源。其優點很明顯,由於ODBC相對OLE DB來說使用得更為普遍,因此可以獲得的ODBC驅動程式相應地要比OLE DB的要多。這樣不一定要得到OLE DB的驅動程式,就可以立即訪問原有的資料系統。
       避免混淆提供者與驅動程式是重要的,圖8-2明確了它們之間的區別:

       提供者位於OLE DB層,而驅動程式位於ODBC層。如果想使用一個ODBC資料來源,需要使用針對ODBC的OLE DB提供者,它會接著使用相應的ODBC驅動程式。如果不需要使用ODBC資料來源,那麼可以使用相應的OLE DB提供者,這些通常稱為本地提供者(native provider)。
       可以清楚地看出使用ODBC提供者意味著需要一個額外的層。因此,當訪問相同的資料時,針對ODBC的OLE DB提供者可能會比本地的OLE DB提供者的速度慢一些。




相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。