Visual FoxPro 已經過時了嗎
恕我直言，這樣的問題我真的聽膩了。這個問題我聽了好幾年了。從謠言出現到今天Visual FoxPro的版本已經生了兩次變化，就是Visual FoxPro 6.0 與2001年春天推出的Visual FoxPro 7.0。根據微軟的官方消息，Visual FoxPro 8（可能是這個名稱吧）已經在研發(fā)之中了。我不敢保證是否會有Visual FoxPro 9.0（這就像我不敢保證微軟是否在那時還存在一樣）?？梢赃@樣認為，只要不出意外情況（比如微軟倒閉、業(yè)界發(fā)生了重大的變革等），Fox就會平穩(wěn)地發(fā)展！
在國外，一個程序員、一家公司把他們使用的開發(fā)工具視作一項投資，作為Visual FoxPro的開發(fā)廠商微軟公司就必須保護客戶的投資權益，這是很基本的商業(yè)原則，微軟絕對不敢隨意淘汰有著50萬用戶的Fox，除非永遠不想賺這50萬用戶的錢了。
為什么會有Visual FoxPro 要淘汰的傳聞呢，我不是很清楚。但這兩年微軟對Visual FoxPro的不宣傳態(tài)度卻是為這股謠言起到了推波助瀾的作用。另外Visual FoxPro 確實是一個容易引起誤會的產品，初級用戶很容易對它產生“不怎么樣的”評判，于是加上那謠言就產生了“Visual FoxPro 就真的要淘汰了”的幻覺了。
為什么說Visual FoxPro 是容易引起誤會的產品呢？我總結以下幾點原因：
面向對象與面向過程之爭
我們說Visual FoxPro是面向對象化的語言，是有根據的。面向對象化的語言必須具備四個特性：抽象（Abstraction）、封裝（Encapsulation）、繼承（Inheritance）、多態(tài)（Polymorphism）。對照一下Visual FoxPro，是不是支持這四大特性！
當然，Visual FoxPro 與C++和Object Pascal 一樣都是歷史悠久的語言，所以語言中有很多面向過程的語素。我知道很多學校在教學中，只是教導學生們使用Visual FoxPro的面向過程的語言特色，而忽視了面向對象的教學，同樣的問題也存在于廣大的 Visual FoxPro 程序員中。我們必須明白：不能因為我們沒有使用Visual FoxPro面向對象的強大功能，而說Visual FoxPro不是面向對象的語言，這就像不能因為天下雨、沒有出太陽，而說太陽被天狗吃掉了——多么的幼稚可笑！
我們知道Visual FoxPro對數據的操作沿用了多年來的面向過程的做法，這與現在流行的開發(fā)工具有很大的不同。我覺得，微軟這樣做是有它的道理的：
第一，面向過程的數據處理，更能發(fā)揮XBase語言體系的靈活與隨意的特色。這一點，你用過其他的數據庫開發(fā)工具，然后再用用Visual FoxPro就明白了。
第二，不直接提供面向對象的數據處理組件，不代表不允許用戶封裝自己的數據處理組件。很多優(yōu)秀的 Fox程序員，都會自己封裝專門數據處理組件，這才是Visual FoxPro編程的高尚境界！
面向記錄與面向集合之爭
根據筆者的淺薄認知，關系型數據庫處理可以分為面向記錄操作和面向集合操作。
各種開發(fā)工具支持的客戶端光標體系就是面向記錄操作的，它們支持記錄之間的絕對定位，更明白地說就是可以在記錄之間導航，諸如：SKIP、GO TOP之類的語句。Visual FoxPro 無疑是此道的絕對高手，20年的語言發(fā)展，聚集了大量面向記錄的語言要素。這是因為這樣，我們才會反復強調：Visual FoxPro的Cursor 體系靈活、強大！
各類大型數據庫，如Oracle、SQL Server 是面向集合處理的代表，看看正統(tǒng)的SQL 語言，絕對沒有數據導航之說，數據記錄之間是平等的，一切都要講關系、擺條件！
隨著技術的發(fā)展，人們開始注意到，不能分割這兩種對數據的操作方式，于是大型數據庫支持了游標語素，Fox也支持符合規(guī)范的SQL 語言。
產品定位導致Visual FoxPro變化不易為人們感覺。微軟要把Visual FoxPro作為三層構架（或是多層構架）的中間層開發(fā)工具。
什么是三層構架呢？第一層是用戶界面:它包含了用戶界面,讓使用者輸入,輸出,查詢等工作；第三層是資料層:它就是用來放資料的地方,一般是指后端數據庫，主要有包括 Oracle、SQL Server 等,它主要是提供一個很大的地方,來有規(guī)則的存放數據；第二層是商務邏輯層（中間層）:有人要說了：存取資料,直接從第一層跳到第二層可不可以？當然可以,沒有人規(guī)定不能走捷徑,而且從數據庫直接抓資料,既快又好,那為什么搞出個第二層呢？
商務規(guī)則是經常變化的,比如上班從8 點改為10 點,那電腦怎那么知道老板因為不景氣少讓大家上二個小時班呢?它一定無法知道,你必須告訴它,這時問題就來了,如果你有很多部電腦,例如:100 臺,你就得一部部換新程序。如果這是一個掛在Internet上的網絡程序，難道總讓用戶download新程序不成？
更重要的是，在大量客戶存在的環(huán)境里，傳統(tǒng)的兩層構架根本沒有能力承擔巨大的工作壓力，必須通過某種中間系統(tǒng)實現壓力平衡，這就是中間層的另一妙用！
中間層是沒有圖形界面設計的代碼編寫，并且是OOP方式的代碼編寫，不僅要熟悉后臺數據庫的特性，還要考慮前臺界面工具的特性，最重要的是商務邏輯的構架，同時還要求懂得IIS、MTS(COM+)、NT的安全設置等復雜枯燥的東西。有趣的是，近年來 Visual FoxPro 的各種改進，更多的是在這些方面下功夫，到了最新版本的Visual FoxPro 7 更是在此方面增加了若干特性，下面就讓我用四個問題來說明Visual FoxPro 在開發(fā)中間層方面的貢獻：
問題一：Visual FoxPro能開發(fā)出穩(wěn)定、有效率的Server程序嗎？能，在1999年發(fā)布的Visual FoxPro SP 3中微軟賦予了Visual FoxPro開發(fā)多線程進程的內組件的能力，并增加了新的運行時刻庫VFPnT.DLL（n代表版本號），支持其運行，在這個運行庫中，刪除了大量老式的和界面控制元素，使得它更小巧。但是由于Visual FoxPro6本身不是很穩(wěn)定（加打SP4或SP5才有所改善），所以這個很棒的功能在Visual FoxPro 6下并不能充分發(fā)揮，直到Visual FoxPro 7出現才使它的顯示出英雄本色！
問題二：分布式的事務、動態(tài)負載平衡怎么實現？Visual FoxPro 7對COM+有很好的支持，借由COM+就可以解決這兩個問題了！
問題三：作為Server程序，客戶程序怎樣與Server交換數據集合？這是Visual FoxPro 6開發(fā)的Server程序的致命弱點，我們知道Visual FoxPro是用來處理數據的，但不能與外界自由交換數據集合會大大降低開發(fā)、使用以及程序運行效率！在Visual FoxPro 7里我們XML就可以快速、輕易的傳遞大型數據集合，真正做到數據集的來去自由?，F在回想Visual FoxPro 6中我們用的那種“循環(huán)+屬性”的做法，真有天上與人間的感受！
問題四：能不能讓Visual FoxPro開發(fā)的Server任由客戶使用，叫干什么就干什么？可以的，在Visual FoxPro 7里提供了一個全新的函數：ExecScript()。有了它，就可以一次執(zhí)行多條客戶端送來的符合Visual FoxPro規(guī)范的語句：你可以定義變量、做查詢、更新數據、修改表結構……
微軟確實實踐著讓Visual FoxPro在中間層運行的承諾。但遺憾的是：由于國內用戶的水平、國內軟件應用的領域，對大多數Fox Fans 無法感受Visual FoxPro日新月異的變化——對他們來說，Visual FoxPro確實“沒有改變”！
Visual FoxPro 只能局限于桌面應用程序的開發(fā)嗎？
技術在進步，軟件技術的應用不斷在拓寬，Internet 已經是眾多開發(fā)工具競相支持的應用領域。Visual FoxPro 從版本 5 開始不斷擴充對Internet的支持，到最新的Visual FoxPro 7 更是增加了對Web Service的支持。我們可以把Visual FoxPro 對Internet的支持分為三大部分：
第一，簡單的HTML的轉換。Visual FoxPro 自帶的“Web 發(fā)布”就是這類型的工具，利用HTML和DHTML的模版，支持Visual FoxPro數據的Web化，這是一種全靜態(tài)的 Web 支持。
第二，適合于企業(yè)內部使用的 Active Document 技術。是不是希望快速、簡單的把Visual FoxPro應用程序轉變?yōu)閃eb 應用程序，這個Active Document 技術就是最佳的選擇。它支持 App 程序運行在IE中，它的缺點是：在客戶端必須安裝Visual FoxPro的運行庫、客戶端與數據庫間依然是緊密的有狀態(tài)的關系，屬于F/S構架——只是界面能夠運行在IE之中了。它的開發(fā)快速以及它依然基于傳統(tǒng)構架，決定了這個技術只能運行在企業(yè)內部，一般不能在廣域網絡中發(fā)布。
這技術是Visual FoxPro 6提出的，當時在 Tool 菜單里還有一個專門的菜單項。到了而今的Visual FoxPro 7，這個菜單項已經取消了，但并不是說Visual FoxPro 7 不支持Active Document，只是這種并不出色的技術沒有必要再放在醒目的位置了。
第三，基于COM 的 Web 應用。
Visual FoxPro 真正能被用于Web 開發(fā)，就是通過 COM 支持的。
這里您要有個認識，作為數據庫開發(fā)工具，Visual FoxPro 不是FronPage這樣的用于開發(fā)Web 界面的工具（也許未來的 Visual FoxPro 會支持 Web 界面的開發(fā)）。Visual FoxPro 完全是作為 Server 運行在網站的后臺，為各種應用提供服務。使用 Visual FoxPro 編寫的 COM 組件能夠被IIS支持，壓在后臺進行各種運作——這就是真正意義上的Visual FoxPro 的Web應用，也是典型的多層構架的中間層！
這個階段，Visual FoxPro 對 Web的支持有可以劃分為三個層次：
FoxISAPI。
這是最先登場的技術，當年 ASP 技術還沒有出現的時候，我們在 IIS 里就可以通過 ISAPI 技術實現動態(tài)網頁開發(fā)。
Web Server
ASP 技術出現了，我們知道 ASP 技術的一大特色就是支持服務器端的組件的應用。用 Visual FoxPro 的編寫的 COM 組件就能運行在 IIS 里，供 ASP 調用。
Web Service
這是 Visual FoxPro 7 的新特性，也是當前最熱門的技術。它與Web Service的最大不同就是：Web Server 組件只能通過 ASP 程序調用，而Web Service可以供任何系統(tǒng)在全球范圍調用，無論客戶端的硬件平臺、軟件平臺，只要它支持SOAP、支持XML就可以了。
更夸張一點說：只要能上網，就可以享用 Web Service 提供的服務！
有人也許會問：我可以用VB、VC++建立對象組件時，為何我要用Visual FoxPro 來建立相同的組件? 微軟對這一問題有專門的評論，大意為：快、重復使用性、跨語言重復使用性?！翱臁笔侵赣肰isual FoxPro開發(fā)的組件擷取、處理資料都極為迅速，并且Visual FoxPro能夠非常迅速的建立字符串。到底有多快，我想數據處理、存取的速度大家平時都領教過了，字符串生成速度我這里有個數據不妨一看，這是臺灣的一位高手做的試驗——將1M的數據寫入文本中，結果VC++ 6.0程序用了3.5秒、VB 6.0程序用了11秒、Java 1.1.5用了24秒、Visual FoxPro 6.0用了7秒；“重復使用性”是指Visual FoxPro具備OOP的功能；“跨語言重復使用性”是指Visual FoxPro編寫的對象編譯以后成為COM、COM+對象組件，這樣就可以在其他語言中使用它了。
不要以為Visual FoxPro是“低端產品",無論從數據庫（DBF Base）品質還是開發(fā)環(huán)境評價Visual FoxPro，它都是一個“高端工具”。
許多人認為Visual FoxPro只能用來開發(fā)單用戶系統(tǒng)或是文件服務器構架的小型網絡系統(tǒng)——這是謬誤——這種無知的言論在許多講C/S、三層構架的書中都有（特別是一些VB、PB、Delphi的數據庫編程書）。我可以很負責任的告訴大家完全可以用Visual FoxPro開發(fā)C/S結構的系統(tǒng)。這里說的C/S構架絕對是正宗的，不是用什么F/S構架在糊弄大家。在C/S構架中我們常常選擇Visual FoxPro作為客戶端開發(fā)工具，以Oracle、SQL Server等網絡數據庫壓在后臺，使用Visual FoxPro內置的Remote View和SPT技術,這樣就可以完美地解決問題。這里不能詳細展開,只特別介紹Visual FoxPro的本地引擎在開發(fā)中的作用。Visual FoxPro的本地引擎特別強大（上文我們說過處理百萬條記錄不費吹灰之力），我們在設計系統(tǒng)時可以十分簡單的將遠程數據與本地數據結合，很簡單、很有效地控制網絡數據流量、提高系統(tǒng)工作效率（我看過不少VB、Delphi、PB的書，他們很少在怎樣控制網絡數據流量、提高系統(tǒng)工作效率論述，不知是不屑一顧，還是其他什么原因）。
我認為Visual FoxPro的本地引擎在C/S構架下起碼有三項偉大的用途。其一：非經常變動數據的本地存儲。我國的郵政編碼與地區(qū)的關系是相對穩(wěn)定的數據，而且數據量也不是太小，我想總有上千個記錄（我沒仔細考察過具體情況），我們把這些信息存儲在客戶端的計算機中，就可以在使用郵政編碼及其相關信息時從本地得到數據，這樣能使高系統(tǒng)效率同時節(jié)省網絡資源（這是C/S開發(fā)的重要原則），只在郵政編碼發(fā)生變化時在服務器上統(tǒng)一更新，下載更新客戶機上的數據。如果用別的軟件實現同樣的功能，絕對比Visual FoxPro麻煩而且效果絕對不及Visual FoxPro，這因為Visual FoxPro的數據引擎直接支持遠程數據讀取，能很好的融合本地數據與遠程數據；其二：離線數據包。單位里總有人出差，在千萬里路之外能不能拿著筆記本為客戶發(fā)訂單、與客戶簽合同，就像在自己的辦公室一樣？當他回到公司時只要把筆記本連到服務器中，發(fā)送更新就行了。Visual FoxPro的離線視圖是經濟且高效安全的方案（當然您可以使用遠程撥入或建一個Web網站，這些Visual FoxPro可能干）。其實離線數據包還有一個重要的功能：當下載的數據是大量的（除非萬不得已請不要這樣設計系統(tǒng)），這種情況下使用離線視圖可以數據集自動轉化為物理表，充分利用Visual FoxPro的高速與靈活，完成后連線更新后端數據源——一切都很簡單。我認為：離線視圖絕對是Visual FoxPro在C/S系統(tǒng)中的一個賣點，雖然ADO也支持類似的東西，但肯定不及Visual FoxPro有效率；其三：數據驅動。您是否知道，Visual FoxPro中絕大多數文件格式實際上都是DBF文件，如DBC、SCX、FRX等，他們都可以由Visual FoxPro的本地引擎驅動完成復雜的任務。在設計C/S結構時如果要存儲用戶設置、自定義文件格式，用Visual FoxPro的本地引擎幫忙絕對比其他軟件簡單，因為你用的是換湯不換藥的方法，但它簡單、有效率。
Visual FoxPro 開發(fā)C/S系統(tǒng)時，最與眾不同的特色就是對遠程數據的操控是通過本地數據庫來實現的，Remote View、Connection都作為本地數據庫的對象被管理起來，完美的銜接本地數據與遠程數據。這種在客戶端建立遠程數據邏輯的做法，與最新的ADO.NET有相似之處！
在三層構架中，Visual FoxPro可以充當任意一層的任務，但本人以為大中型系統(tǒng)的數據庫部分應以網絡數據庫為主?？蛻舳私缑嬗肰isual FoxPro也是可以的，但一般限于企業(yè)內部，在Internet上我們通常使用IE作為客戶界面。在三層構架中Visual FoxPro最勝任中間層的開發(fā),它簡單（開發(fā)難度與普通的Visual FoxPro項目相差不大）、快速的字符串生成、支持COM技術、它支持（MTS）COM+技術、它支持XML（Visual FoxPro 7.0提供3個與XML有關的函數）、它具有強大本地數據引擎、靈活的數據處理方式、它支持多線程的服務組件的開發(fā)。
可能有人要問：用ASP+腳本語言一樣可以開發(fā)Web系統(tǒng)，何必加個中間層。的確，目前在市面上與多討論Web的書都直接使用腳本語言來開發(fā)整個系統(tǒng)，這是十分不正確的做法，甚至有寫書還說硬件越來越快，因此使用腳本語言來開發(fā)整個系統(tǒng)并沒有什么關系。會說出這樣話的作者通常都是沒有實際開發(fā)Web應用經驗的人。腳本語言，如VBScript是一種解釋性語言，運行效率很低，他們只合適作為膠水程序。開發(fā)Web系統(tǒng)正統(tǒng)的做法是：把應用邏輯編寫成COM、DCOM對象，然后用少量的腳本語言來驅動/使用這些對象。這樣系統(tǒng)開發(fā)時工作量會大一些，但它符合開發(fā)任何數據庫應用程序的最基本的原則：分離應用邏輯與用戶界面。這樣系統(tǒng)就會變的容易維護了——你可以經常變換那些膠水程序來改變Web頁面，應用邏輯變換時你又可以改變某一個邏輯對象，而不用為雜亂且關系復雜的代碼發(fā)愁。再者，由于Visual FoxPro是高效、靈活的數據處理語言，任何商業(yè)邏輯都可以用它來代碼化，并且您可以獲得幾十倍甚至上百倍于ASP+腳本語言的運行效率，以及更為強健的執(zhí)行效果。
Visual FoxPro 的語言看上去蠻難的。
人們在贊揚 Visual FoxPro 始終是褒揚他的易學易用，我不同意這種觀點（我不知道他們站在什么立場上說話）。我看問題的角度是“成為一名還過得去的 Visual FoxPro 程序員”，我的結論是Visual FoxPro 作為一個開發(fā)工具并不是好學的。這不是說Visual FoxPro的語法、概念像C那么繁復，而是指：即使是簡單的應用，也要掌握很多Visual FoxPro的概念、語法、函數，可能還要較深入了解OOP——往往讓人摸不到深淺。比如，拿數據庫系統(tǒng)最重要的功能——查詢來講，Visual FoxPro就“花樣繁多”。我曾統(tǒng)計過，不算“List、Browse"等交互式命令，Visual FoxPro起碼支持4條命令（Find,Seek,Locate,Select-SQL）、3個函數(Lookup(),Seek(),Indexseek()),（當然其中有的已經淘汰）這些命令的關鍵字、函數的參數眾多，有的要求索引， 有的可以用索引但要求優(yōu)化索引……而這在VB、Delphi中絕對就只是兩三個方法的事情。從上面的例子中如果您只看到了Visual FoxPro的繁雜，那么您就完全錯了：在VB、Delphi實現查詢功能的原理與Visual FoxPro應是一樣的，但他們封裝了許多環(huán)節(jié)，而Visual FoxPro就把許多東西更低階（當然不如VC++那么低層次，但是已經比使用對象的語言難多了）的展示給我們，所以Visual FoxPro的開發(fā)者往往比使用其他的開發(fā)工具開發(fā)者更會思考、更懂得的數據庫開發(fā)的真諦，因為工具逼迫他們朝這個方向努力……
用Visual FoxPro有助于提高程序員對數據庫概念的理解。許多在Visual FoxPro程序員中不是問題的問題往往成為那些使用對象處理數據的程序員的噩夢。比如在Visual FoxPro中數據緩沖、事務處理都是重要的概念（事實上要干活就必須了解這些東西），在其他開發(fā)環(huán)境中一味強調方便快速往往忽視程序員的基本概念培養(yǎng)，編出的東西要么效率不高、要么老出問題。讀書人都懂得：基本概念、基本理論是命根子，這就是Visual FoxPro帶給我們的好處。
有趣的是Visual FoxPro繁、難也就到這個程度了 ，他的學習難度曲線是所有語言中最平穩(wěn)的——不像在有些語言中，基礎開發(fā)十分容易，一旦深入卻難度很高。在Visual FoxPro中初級應用、中級應用、高級應用的難度差異很小——就是那些似曾相識的語句、易于理解的函數。Visual FoxPro的這種高級應用不太難，初級應用不十分容易的特性，對初入門者來講是無法體會其中的妙處的，這就造成了Visual FoxPro的不太友好形象；
同時，Visual FoxPro的難度卻帶來了很多的好處（前文我已談了很多），Visual FoxPro比其他語言在數據處理上更快速、更靈活，數據處理方式更多、更完備。設想一下用Visual FoxPro開發(fā)數據對象時，我們可以使用豐富多彩的語句、函數，實現十分復雜、變化多端的功能，用其他語言開發(fā)數據對象，它們的功能只能是建立在已有的數據對象的功能之上（這叫繼承），變化就少了，功能就弱了。如果要實現Visual FoxPro的Xbase+SQL 那樣靈活、強大的功能恐怕要使用底層的API了——這太可怕了！
OOP不僅是指“面向對象”的開發(fā)環(huán)境，更是一種開發(fā)思想、開發(fā)技術，Visual FoxPro 在后者上做得更好。
我們講過Visual FoxPro完全支持OOP的開發(fā)，但有趣的是在數據處理方面，微軟實際上沒有提供什么現成的對象（FFC是Visual FoxPro 6.0才有的，且封裝性、適應性都不盡如人意），這一點我不知是Visual FoxPro的福氣還是禍害。說“福氣”這將逼迫程序員掌握這門并不太簡單的技術（可能用“思想方法”更恰當），而不是簡單地使用對象。OOP對于中間層的開發(fā)來講是很重要的，因為COM組件必須是建立在OOP思想上的，要開發(fā)這種組件就必須掌握OOP技術；講“禍害”這使Visual FoxPro變得不易于學習和使用了（就我個人而言，真正體會到“用Visual FoxPro應會編制數據處理對象”這一問題也是在使用了Visual FoxPro好長時間之后的事情了）。事實上現在很多誹謗攻擊Visual FoxPro的人都沒有深刻的認識這一問題——他們只感到Visual FoxPro用起來不及Delphi、PB、VB容易，但他們從不想該怎樣開發(fā)數據處理對象，到編寫COM組件時就要他們的命了。那些“精英們”大多不懂OOP，他們只懂“點”操作符號——仿佛對象的使用就是OOP，他們有什么資格來批評我們呢？
Visual FoxPro的界面能力真的很差嗎？
我認為作為數據庫系統(tǒng)的開發(fā)工具微軟為我們提供的那些內置控件加上十幾個附送的ActiveX控件已經夠用了。
我們討論Visual FoxPro控件應從兩方面入手，第一就是界面美觀問題，再就是數據處理、分析是否方便。很多人很在意的前一個問題，我倒是不以為然——控件不多特別是美化界面的控件不多并不代表Visual FoxPro就開發(fā)不出賞心悅目的軟件，我的感受是軟件界面的專業(yè)化程度、高級別的審美、整體的效果要比個別的界面特效重要千萬倍，實際效果可要好上千萬倍?？纯磭庥肰isual FoxPro編制的程序您就會明白這個道理了；我對Visual FoxPro的不滿在于數據處理、分析控件不全，特別是缺少了一批數據分析控件。比如沒有可以與數據捆綁的圖表控件、沒有可以列示捆綁交叉表的表格控件、沒有可以捆綁數據的數據透視表格控件……在這個問題上Visual FoxPro確實應該向Delphi、PB等軟件學習，這是我們對未來的Visual FoxPro的期望！
Visual FoxPro與OLE DB、ADO
ADO是Windows環(huán)境下主流的數據存取的解決方案，那些以對象操作數據的語言基本上都使用ADO實現數據存取，如：VC++、VB、Delphi。在Visual FoxPro的開發(fā)環(huán)境中好像看不到ADO的影子，是不是Visual FoxPro不支持ADO呢？ADO其實是一組COM對象，Visual FoxPro支持COM，當然支持ADO。
我認為：Visual FoxPro對ADO的支持只是停留在較低的水平。這并不是說Visual FoxPro限制了什么ADO的功能（所有功能都能用），而是指：用起來不方便，不像在VB、Delphi中方便。這種不方便主要體現在ADO的Recordset無法與Visual FoxPro的內置控件捆綁。其原因是：Visual FoxPro 不認識ADO的Recordset，只能將記錄逐條讀取，而不是一下子認得整個Recordset。這樣數據就不能被捆綁了，同時也不能對ADO直接使用Visual FoxPro強大的數據處理功能（ADO是用來存取數據而處理數據還要靠客戶軟件）。
就象Visual FoxPro使用ODBC連接遠程數據源那樣，ADO通過OLE-DB與數據提供者對話。 （By the way: Visual FoxPro 7是OLE-DB提供者，這樣就可以 通過正宗的OLE-DB驅動程序在其他開發(fā)工具中使用ADO存取Visual FoxPro數據了 。）
ADO能為Visual FoxPro帶來什么？首先要注意的是：ADO與Visual FoxPro的數據引擎是毫無關系的系統(tǒng)，從某種程度上講ADO的出現為Visual FoxPro提供了一種全新的遠程數據處理方式。
ADO是多層應用程序中數據集合傳遞的最好解決方案。如果我們用Visual FoxPro開發(fā)了一個中間層系統(tǒng)，用VB開發(fā)了用戶界面，當中間層要傳遞一個cursor到VB的客戶端就不可以使用Visual FoxPro的cursor或DBF，因為VB不認得他們。使用ADO的Recordset就可以解決問題，因為大家都認得他；Visual FoxPro 只能通過Visual FoxPro 7支持XML后才能彌補Visual FoxPro本地引擎在應用程序傳遞數據集的不足。
ADO可以存取非關系型數據庫。ADO是微軟的Universal Data Access構架的主將，它可以存取Excel等非關系型數據數據庫的數據。通過ODBC存取遠程數據的Visual FoxPro就無此能力了。但是我使用了ADO存取Excel后很失望，因為連接必須是獨占的，所以這種功能帶給我們的幫助只是有限的！
ADO可以彌補Visual FoxPro在遠程數據存取時的不足之處。譬如Visual FoxPro不認得SQL Server中nText、nVarchar、nChar等數據類型，但ADO可以。
在Visual FoxPro使用ADO存在如下缺點：
Visual FoxPro只能通過COM的方式識別ADO的Recordset，不能像表格那樣讀寫它，這樣就出現了兩個問題：Recordset無法與Visual FoxPro的內置控件捆綁；無法直接使用Visual FoxPro強大的數據處理功能（ADO是用來存取數據而處理數據還要靠客戶軟件）。
Visual FoxPro中使用代碼實現ADO的全部功能，但代碼量大、書寫麻煩。
對待以上不足Visual FoxPro開發(fā)小組在Visual FoxPro 6推出不久后就發(fā)布了一個叫VFPCOM.DLL的組件，可以用它部分解決ADO的Recordset與Visual FoxPro的cursor的轉換和ADO事件的綁定 ，Visual FoxPro 更是內置支持 COM 事件綁定。在本文的第一版中，筆者曾有這樣的希望：“Visual FoxPro 更具效率的支持ADO”?，F在我的看法有了一些改變，我認為在 Visual FoxPro 處理數據，無論是本地、還是遠程數據，無論是什么構架的系統(tǒng)，最佳的解決方案認識內置的數據引擎，而不是現在流行的ADO,現在 Visual FoxPro對ADO的支持程度已經足夠了！
Visual FoxPro的數據引擎與ADO相比有什么優(yōu)勢呢？
Visual FoxPro數據引擎系統(tǒng)資源耗用小，ADO畢竟是COM組件要花用更多的資源。
作為系統(tǒng)共用組件，使用ADO可能會在不同應用系統(tǒng)中產生ADO的版本問題，這就像我們常遇見的ActiveX的控件版本問題。
ADO只是數據存取組件，它沒有數據處理功能，要處理數據必須使用客戶應用程序，如VB、Delphi。Visual FoxPro數據引擎同時支持數據存取、數據處理，我已多次強調Visual FoxPro在這兩方面的偉大功能；
ADO沒有本地數據庫作為強大的支持，有需要將遠端數據暫時存放在物理文件中ADO絕對不及Visual FoxPro。Visual FoxPro的數據庫是桌面數據庫中最好的，遠端數據暫存其中不僅方便，而且伸縮性強。
使用ADO從數據源獲得數據以后，再要對數據集合進行分組、查詢、匯總是非常麻煩的事情，但是Visual FoxPro支持對Cursor的數據處理，我們可以使用絕大多數XBase語言（除了ZAP和Pack之類的表維護語言之外），還可以對Cursor執(zhí)行SQL語句——這種強大的威力，絕非ADO所能比擬。
開發(fā)單機程序時，絕對不要使用ADO，這樣做既沒開發(fā)效率也沒運行效率；開發(fā)C/S系統(tǒng)時我們應選用Visual FoxPro的SPT和Remote View，它們完全可以很完美的解決問題（已經有很多很多成功經驗），不需要舍近求遠地使用ADO；在中間層開發(fā)時，可以考慮使用ADO，我們?yōu)樵诖朔N情況下使用ADO的開發(fā)效率是蠻高的，因為這時所有的代碼都要我們用一句、一句的寫出來（在其他開發(fā)環(huán)境也一樣），Visual FoxPro的語法簡單再加上Visual FoxPro 7的極為強大Intellisense功能（真的很快并且可以由用戶自定義），也許我們還會占些便宜的。
雖然ADO與Visual FoxPro是完全無關的系統(tǒng)，但他們卻有共同的母親——FoxPro 開發(fā)小組，原來ADO的光標集（Cursor Engine）是他們開發(fā)的。如果你同時了解ADO與Visual FoxPro，你會發(fā)現ADO的很多思路與Visual FoxPro一模一樣……我總是拿這個典故說服那些不相信Visual FoxPro的人：最流行的ADO的光標集是FoxPro 開發(fā)小組寫的，有什么理由懷疑Visual FoxPro的數據引擎——它是世界上最棒的！
Visual FoxPro是一種歷史悠久的產品，很多用戶是從FoxBASE到FoxPro到Visual FoxPro，這樣一步一步過來的。歷史的積淀多了，歷史的包袱也重了——許多程序員往往抓住老產品而忘了深入鉆研新產品的新特性，這是一種悲哀。
我遇到許多所謂會使用Visual FoxPro的人，還口口聲聲叫“Query Design”為“RQBE”，朋友那可是DOS時代的概念了。
很多人不仔細鉆研Visual FoxPro，只是從其他工具中看到某項功能，憑空想象就說：Visual FoxPro不支持的。Delphi中特別指出它有異構數據關聯(lián)能力，比如：父表是SQL Server數據，子表是Access數據，要求建立關聯(lián)，實現“一多關系”。在Delphi要求使用特別的SQL語法來實現該功能。Visual FoxPro的文檔里好像沒特別說明這項功能，是不是沒有呢？如果你深刻理解Visual FoxPro的遠程視圖及Cursor的用法，答案很容易得到。事實上，用Visual FoxPro能更直接、簡單實現的實現：建兩條“連接”、兩個“遠程視圖”，對子表加索引，Set relation to，set skip to……
反過來Visual FoxPro能實現的功能，Delphi的BDE（Delphi的本地引擎）卻不能：Visual FoxPro的遠程視圖能夠將多個表關聯(lián)后的結果集設定為“可更新”，并在數據變動后自動產生Update子句分別更新后臺數據。例如：對SQL Server中Pubs數據庫建立連接，新建遠程視圖為：
CREATE SQL VIEW TEST VIEW REMOTE CONNECTION CONNECTION1 AS SELECT Publishers.pub_id, Publishers.pub_name, Titles.title_id, Titles.title, Titles.price, Authors.au_id, Authors.au_lname, Authors.au_fname, Authors.phone, Authors.address FROM dbo.publishers Publishers, dbo.titles Titles, dbo.titleauthor Titleauthor, dbo.authors Authors WHERE Titles.pub_id = Publishers.pub_id AND Titleauthor.title_id = Titles.title_id AND Authors.au_id = Titleauthor.au_id ORDER BY Publishers.pub_id
這是四個表間的關系，算是比較復雜的SQL語句。別擔心，這一切在Visual FoxPro只不過是用鼠標在“視圖設計器”點擊幾次就行了。在您對視圖進行“添加、刪除、修改”并發(fā)送更新時， Visual FoxPro會進行分析地智能，產生Update字句分別將變化更新到后端若干個表中。而Delphi的BDE只能對Xbase數據源有此的作用，對其他的數據源都無此功能。Visual FoxPro可以支持所有的ODBC數據源（只要數據源本身支持），如：Oracle、SQL Server，Access……當然在Delphi 5.X中可以通過ADO彌補此缺陷，但Visual FoxPro同樣支持ADO。Visual FoxPro的程序員要有這樣的信心：Visual FoxPro為我們提供了最好的本地引擎！
古人云：欲善其事、必先利其器。所以我們不要指責工具怎么、怎么，多看看自己用好了沒有!
聯(lián)系客服
