維's profileIT : 是工作還是嗜好?PhotosBlogListsMore  |  Tools Help |
|
August 27 Embarcadero正式發佈Delphi 2009/C++Builder 2009Embarcadero在美國時間8/25日正式發表了開發代號為Tiburon的Delphi 2009/C++Builder 2009，其實對於參加過多次Borland/CodeGear beta產品測試的我來說早就在數天前就大約猜到了Tiburon將在8月底左右正式發表，為什麼呢?因為在進入8月20日左右Tiburon的beta 版本就開始愈來愈頻繁，從早期大約每個星期一個版本，到2,3天一個版本，再到8月中左右開始每天一個版本，到8月20日左右一天2到3個版本就可以推測Tiburon離正式發表不久了，因為最後頻繁的beta版本都應該都是在修正必須修改的臭蟲。 有異於以往Delphi/BCB一前一後發表的模型，Tiburon這次同時公佈了Delphi 2009和C++Builder 2009，這代表了從Tiburon開始Delphi和C++Builder使用的核心RTL/VCL都已經同步化，在編譯器方面Delphi的編譯器和C++Builder的編譯器也進行了更緊密的結合和同步化，因此這也讓如何進行Delphi 2009和C++Builder 2009產品技術發表會產生了令人頭痛的問題，由於場地和時間的限制，因此Embarcadero決定先在9月進行Delphi 2009的產品技術發表會:
待10月初再進行C++Builder 2009產品技術發表會，如此一來可以讓不同的使用者參加最適合的產品技術發表會。有人可能會說為什麼不同時進行Delphi 2009和C++Builder 2009產品技術發表會呢? 這是因為這次雖然Tiburon同時發佈了Delphi 2009和C++Builder 2009，但是這次的Delphi 2009和C++Builder 2009雖然擁有許多相同的新功能，但是C++Builder 2009擁有更多獨特的功能，例如Together For C++，Cpp0x，支援ACE/Boost等，因此在發表會的內容和範例上都會和Delphi 2009有著許多的不同，因此Embarcadero才決定讓Delphi和C++Builder的使用者參加各自專屬的產品技術發表會，這樣會讓不同的工具使用者盡興而歸。 如果您想參加Delphi 2009的產品技術發表會，您可以藉由下面的URL報名參加: 如果您想參加C++Builder 2009的產品技術發表會，請您稍待一會，一有確定的訊息我就會公告出來。 Have Fun! Embarcadero正式發佈Delphi 2009/C++Builder 2009Embarcadero在美國時間8/25日正式發表了開發代號為Tiburon的Delphi 2009/C++Builder 2009，其實對於參加過多次Borland/CodeGear beta產品測試的我來說早就在數天前就大約猜到了Tiburon將在8月底左右正式發表，為什麼呢?因為在進入8月20日左右Tiburon的beta 版本就開始愈來愈頻繁，從早期大約每個星期一個版本，到2,3天一個版本，再到8月中左右開始每天一個版本，到8月20日左右一天2到3個版本就可以推測Tiburon離正式發表不久了，因為最後頻繁的beta版本都應該都是在修正必須修改的臭蟲。 有異於以往Delphi/BCB一前一後發表的模型，Tiburon這次同時公佈了Delphi 2009和C++Builder 2009，這代表了從Tiburon開始Delphi和C++Builder使用的核心RTL/VCL都已經同步化，在編譯器方面Delphi的編譯器和C++Builder的編譯器也進行了更緊密的結合和同步化，因此這也讓如何進行Delphi 2009和C++Builder 2009產品技術發表會產生了令人頭痛的問題，由於場地和時間的限制，因此Embarcadero決定先在9月進行Delphi 2009的產品技術發表會:
待10月初再進行C++Builder 2009產品技術發表會，如此一來可以讓不同的使用者參加最適合的產品技術發表會。有人可能會說為什麼不同時進行Delphi 2009和C++Builder 2009產品技術發表會呢? 這是因為這次雖然Tiburon同時發佈了Delphi 2009和C++Builder 2009，但是這次的Delphi 2009和C++Builder 2009雖然擁有許多相同的新功能，但是C++Builder 2009擁有更多獨特的功能，例如Together For C++，Cpp0x，支援ACE/Boost等，因此在發表會的內容和範例上都會和Delphi 2009有著許多的不同，因此Embarcadero才決定讓Delphi和C++Builder的使用者參加各自專屬的產品技術發表會，這樣會讓不同的工具使用者盡興而歸。 如果您想參加Delphi 2009的產品技術發表會，您可以藉由下面的URL報名參加: 如果您想參加C++Builder 2009的產品技術發表會，請您稍待一會，一有確定的訊息我就會公告出來。 Have Fun! August 21 Tiburon遊記4 結合分散式DataSnap和JSON架構隨著Tiburon推出的日期日益接近，每天的Beta Build也變得更密集了，我報上去的許多中文/Unicode相關的臭蟲也不斷的被修正，Tiburon的IDE也日益更加穩定，看來距離Embarcadero正式推出Delphi/BCB 2009的日子應該是不遠了，記得在去年初時想到不知Unicode的Delphi/BCB版本何時才會出來，沒想到日子過的這麼快，支援Unicode的Delphi/BCB版本即將出現在我們面前，而這個版本對於許多的Delphi/BCB開發人員來說是極為重要的一個版本，因為Delphi/BCB 2009是一個關鍵的昇級版本，在這個版本之後Delphi/BCB將進入64位元和多核心的世界，因此把握Delphi/BCB 2009昇級舊系統並且使用Delphi/BCB 2009開發現在和未來的系統以便相容於未來的64位元和多核心趨勢是最為明智的選擇。 在上一篇文章中我介紹了如何使用Tiburon建立一個簡易的以JSON為基礎的分散式架構，在本篇文章中我將繼續討論如何結合原本Delphi/BCB開發人員熟悉的DataSnap架構和JSON架構以便開發出新一代以JSON為基礎的分散式架構，如果您使用過DataSnap，又閱讀了前面數篇文章，那麼這將非常的簡單，畢竟RAD精神就是讓您簡單的就能夠開發出您要的架構，不是嗎?當然如果您想要追根究底的瞭解DataSnap/JSON技術，提供了完整原始程式碼的VCL框架也可以讓您學習到許多的技術。 為了簡單說明起見，我延用『Tiburon遊記3 動手建立一個DataSnap JSON伺服器吧』這篇文章基本的內容來建立分散式DataSnap和JSON架構，請您交互參考本篇和『Tiburon遊記3 動手建立一個DataSnap JSON伺服器吧』文章的內容。 步驟 1 – 建立分散式JSON伺服器 前5步驟是一樣的，接著 6. 選擇File|New|Other，建立Server Module如下: Server Module的型態是TDSServerModule，讓我們看看它的定義: {$MethodInfo ON} TDSServerModule = class(TProviderDataModule) end; {$MethodInfo OFF} 果然，TDSServerModule即是資料模組，只是以{$MethodInfo ON}和{$MethodInfo OFF}包圍宣告，因此它的繼承類中宣告的方法將可輸出到用戶端。 7. 在Server Module中拖曳資料庫中的資料表到其中，例如下圖是我把Blackfish SQL中的SEMINARS資料表拖曳到Server Module上: 8. 在Server Module的類別中，我宣告和實作了一個public方法GetSeminars如下: function TDSServerModule1.GetSeminars : TDataSet; begin Self.SEMINARS.Open; Result := Self.SEMINARS; end; 由於在DataSnap 4中我可以直接把TDataSet傳遞到用戶端，因此在GetSeminars中我只需要把SEMINARS這個TSQLDataSet物件傳遞回用戶端即可，DataSnap會自動以JSON封裝TDataSet的物件。 9. 在JSON伺服器的TDSServerClass元件的OnGetClass事件中輸出Server Module類別: procedure TForm10.DSServerClass1GetClass(DSServerClass: TDSServerClass; var PersistentClass: TPersistentClass); begin PersistentClass := TDSServerModule1; end; 現在編譯並且執行JSON伺服器，接著就可以建立分散式用戶端了。 步驟 2 – 建立分散式用戶端 前3步驟是一樣的，只是TSqlServerMethod元件的ServerMethodName特性連結到TDSServerModule1.GetSeminars方法。 4. 在主表單中加入DataSetProvider元件連結到TSqlServerMethod，這是因為TSqlServerMethod呼叫的TDSServerModule1.GetSeminars方法會回傳一個TDataSet，因此就可以做為資料提供者，DataSetProvider元件就可以以這個回傳的TDataSet做為資料的來源 5. 放入TClientDataSet元件，連結到DataSetProvider元件 從步驟4,5可以看到這和以前使用DataSnap開發用戶端是 樣的，但是現在是連結到JSON伺服器。 6. 最後再放資料感知元件和一個Button元件，在Button元件中撰寫: procedure TForm11.Button1Click(Sender: TObject); begin Self.ClientDataSet1.Active := True; end; 以開啟並且存取資料。 下圖是我同時執行三個分散式用戶端同時存取一個步驟1開發的JSON伺服器的畫面: 您可以看到用戶端成功的從JSON伺服器取得了資料並且顯示在資料感知元件中。 請注意這個應用系統重要的意義，用戶端不需要再載入各種資料庫驅動程式，只需要DataSnap的用戶端DLL和程式本身就可以從JSON伺服器取得資料，因為現在資料都以JSON格式傳遞，DataSnap 4這種用戶端是真正的thin-client。 使用Tiburon開發JSON架構的分散式應用系統是不是又簡單，又強大呢?如果您需要更多的處理能力，那麼VCL框架中提供了許多相關的JSON處理類別可以讓您呼叫使用，這些進階的主題就留待其他文章來討論了。 Have Fun!
August 12 Tiburon遊記3 動手建立一個DataSnap JSON伺服器吧 也許讓我們先動手用Tiburon實作一個DataSnap JSON分散式架構再搭配前面說明的觀念的話，各位將會更加瞭解Tiburon把這些強大的功能做得多麼的方便。 DataSnap新的JSON分散式架構可以有許多不同的型態，更可以結合資料庫和Web應用程式，不過在一開始讓我們先學習如何建立最簡單的JSON分散式架構，下面是我們即將實作的JSON分散式架構的簡單說明: 1. 建立一個分散式JSON伺服器，在JSON伺服器中提供伺服端的服務方法讓用戶端`可以呼叫使用 2. 建立一個DataSnap用戶端應用程式，藉由TCP + JSON架構呼叫分散式JSON伺服器提供的服務 在步驟1中我們將看到Tiburon新的Reflect功能如何把伺服端的服務方法輸出，而步驟2我們則可以看到Tiburon的DataSnap元件如何在原有的元件中加入可以處理JSON分散式架構的功能。 步驟 1 – 建立分散式JSON伺服器 要建立分散式JSON伺服器非常的簡單，它的步驟如下: 1. 建立一個VCL Form的應用程式 2. 在主表單中加入TDSServer元件，TDSServer元件負責JSON伺服器和用戶端的生命週期管理，並且提供了許多管理的機制。 3. 在主表單中加入TDSTCPServerTransport元件，TDSTCPServerTransport元件使用Indy做為底層TCP通訊元件，TDSTCPServerTransport元件內定上使用211通信埠做為和用戶端連結的通信埠，它並且可以提供通訊池的功能以便有效率的使用伺服器的資源 4. 在主表單中加入TDSServerClass元件，TDSServerClass元件可以把伺服器中的類別輸出給用戶端呼叫，或是把資料模組，遠端資料模組中的方法輸出給用戶端呼叫-。TDSServerClass元件藉由Tiburon新強化的RTTI和Reflect程式單元中的功能以達成這種能力。對於需要輸出服務給用戶端的類別，資料模組或是遠端資料模組，必須使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍類別宣告。 5. 連結TDSTCPServerTransport元件到TDSServer元件，此時主表單應該看起來如下: 現在在這個範例VCL Form的應用程式專案中加入一個新的程式單元，並且撰寫如下的程式碼: unit uServerMethod; interface uses Sysutils, classes; type {$MethodInfo ON} TServerMethodClass = class(TPersistent) public function Hello(const Name: string): string; end; {$MethodInfo OFF} implementation { TServerMethodClass } function TServerMethodClass.Hello(const Name: string): string; begin Result := 'Hello ' + Name; end; end. 各位可以看到上面宣告了一個TServerMethodClass，它必須從TPersistent類別繼承下來，由於它需要函式Hello到用戶端，因此在TServerMethodClass類別之前和之後使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍，如此一來Tiburon的編譯器在編譯這個類別時便會產生額外的RTTI資訊。 6. 在TDSServerClass元件的OnGetClass事件處理函式中撰寫如下的程式碼: procedure TForm6.DSServerClass1GetClass(DSServerClass: TDSServerClass; var PersistentClass: TPersistentClass); begin PersistentClass := TServerMethodClass; end; TDSServerClass元件的OnGetClass事件是用戶端向DataSnap JSON伺服器查詢可呼叫的服務類別時被呼叫，由於在這個範例中我們是要輸出TServerMethodClass類別之中的Hello函式，因此在OnGetClass事件處理函式中把參數PersistentClass設定為TServerMethodClass類別。 現在這個分散式JSON伺服器已經完成，編譯它並且執行它，現在我們就擁有了一個不再需要使用COM/COM+的分散式伺服器了，它簡單，方便又快速，接下來我們就可以建立用戶端應用程式來呼叫它提供的服務方法了。 步驟 2 – 建立分散式用戶端 要建立分散式用戶端也非常的簡單，它的步驟如下: 1. 建立一個VCL Form的應用程式 2. 在主表單中加入TSQLConnection元件，在它的Driver特性中選擇使用DataSnap，並且在HostName中輸入分散式JSON伺服器的名稱，由於我們是在相同的機器中執行，因此可以輸入localhost。另外注意它的Port特性值也是內定為211，各位可以參考下面的圖形: 3. 在主表單中加入TSqlServerMethod元件，連結它到步驟1的TSQLConnection元件，此時下拉它的ServerMethodName特性便可以看到許多伺服器輸出的方法，其中有許多方法是和管理有關的，我們以後有機會再說明，在這些輸出的方法中我們可以找到分散式JSON伺服器輸出的TServerMethodClass.Hello，如下圖所示，請選擇TServerMethodClass.Hello。 TSqlServerMethod元件可以讓開發人員在用戶端呼叫遠端分散式JSON伺服器輸出的服務方法。 4. 最後在主表單的Button控制項的OnClick事件處理函式中撰寫如下的程式碼: 01 procedure TForm7.Button1Click(Sender: TObject); 02 begin 03 Self.SqlServerMethod1.ParamByName('Name').Value := Edit1.Text; 04 Self.SqlServerMethod1.ExecuteMethod; 05 Edit2.Text := Self.SqlServerMethod1.ParamByName('ReturnParameter').AsString; 06 end; 請注意在03行中我們設定TSqlServerMethod元件的Param特性中’Name’這個參數的數值，但是’Name’這個參數是從那裡來的? 請回頭看看前面TServerMethodClass.Hello函式的宣告原型，它接受一個參數，它的名稱就是’Name’，因此TSqlServerMethod元件可以分析遠端JSON伺服器輸出的方法，每一個參數的名稱就成為TSqlServerMethod元件的Param特性中的名稱，而當TSqlServerMethod元件呼叫ExecuteMethod方法真正的執行完畢遠端JSON伺服器輸出的方法後，如果遠端JSON伺服器輸出的方法會回傳函式值，接著開發人員可以藉由'ReturnParameter'這個名稱的參數來取得執行的結果，如同上面05行所示。 現在我們執行用戶端，點選按鈕就可以看到遠端JSON伺服器輸出的方法果然正確回傳了執行結果。 使用簡單的Delphi Reflect功能 Tiburon強化了RTTI並且提供了簡易的Reflect程式單元可以讓JSON伺服器輸出服務到用戶端，我們也可以利用這個功能來驗證一下。 首先我建立一個新的VCL應用程式，在專案中建立兩個額外的類別，一個類別使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍: unit uServerMethod; interface uses Sysutils, classes; type {$MethodInfo ON} TServerMethodClass = class(TPersistent) public function SayHello(const Name: string): string; function GetReflectMessage : String; procedure ReflectMe; private FData : String; end; {$MethodInfo OFF} 另外一個則否: unit u沒有MethodInfo的程式單元; interface uses Sysutils, classes; type TServerMethodWithoutMethodInfoClass = class(TPersistent) public function SayHello(const Name: string): string; function GetReflectMessage : String; procedure ReflectMe; private FData : String; end; 各位可以看到Tiburon支援了Unicode之後連程式單元的名稱都可以使用中文命名。 接著我在主表單中加入參考ObjAuto程式單元，並且使用下面的程式碼就可以取得類別方法的資訊: procedure TForm7.btn有MethodInfo的按鈕Click(Sender: TObject); var aClassObj : TServerMethodClass; mdArray : TMethodInfoArray; iCount: Integer; begin aClassObj := TServerMethodClass.Create; try mdArray := ObjAuto.GetMethods(aClassObj.ClassType); for iCount := 0 to Length(mdArray) - 1 do begin ListBox1.Items.Add(mdArray[iCount].Name); end; finally aClassObj.Free; end; end; procedure TForm7.Button2Click(Sender: TObject); var aClassObj : TServerMethodWithoutMethodInfoClass; mdArray : TMethodInfoArray; iCount: Integer; begin aClassObj := TServerMethodWithoutMethodInfoClass.Create; try mdArray := ObjAuto.GetMethods(aClassObj.ClassType); for iCount := 0 to Length(mdArray) - 1 do begin ListBox1.Items.Add(mdArray[iCount].Name); end; finally aClassObj.Free; end; end; ObjAuto.GetMethods可以取得類別方法的資訊，如果類別沒有使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍，那麼就無法產生足夠的RTTI資訊，因此用戶端將無法存取(看到)類別中的方法。現在執行這個範例VCL應用程式，我們可以看到左邊的ListBox可以顯示TServerMethodClass類別中的方法，而右邊的ListBox則無法顯示TServerMethodWithoutMethodInfoClass類別中的方法。 下圖是我使用TCP Viewer觀查前面分散式JSON伺服器和分散式用戶端之間訊息的結果，我們可以看到它們之間的確是使用JSON格式在傳遞訊息。 Tiburon的分散式JSON架構除了可以輸出伺服器的服務之外，也可以結合資料庫實現真正的Thin-Client，離線資料架構型態的應用系統，這些都基於Delphi開發人員原本就熟悉的DataSnap架構，我很快的會寫一小篇文章展示它是多麼的容易而且又是使用我們熟悉的DataSnap元件。 Have Fun! August 05 Tiburon遊記2 DataSnap和JSON什麼是JSON，我想我不必多說，因為Internet上一堆有關JSON的說明各位可以自行搜尋，簡單的說JSON是一種資料傳遞的格式，流行於JavaScript和Ajax的世界。OK，那麼JSON和DataSnap又有什麼關係? 當DataSnap應用於分散式架構時不是使用COM/COM+嗎?Tiburon的DataSnap為什麼要使用JSON呢? 其實這些問題在我第一次知道DataSnap使用JSON時也立刻出現在我腦中，不過一經思索很多問題的答案就立刻浮現了出來而且也立刻延伸出了許多其他的想法，知道為什麼嗎? 因為在我觀察任何技術時我還是喜歡馬上看看站在這個技術後面的人的背景以及這個技術代表的趨勢，現在讓我還原一下當初我腦中思考的過程。 還記得Steve嗎?它現在是Delphi/C++Builder在資料存取技術方面的架構師，我以前也寫過有關Steve的文章，其中敘述了Steve是來自Java的背景，因此在VCL架框中屬於Steve小團隊開發的程式碼中我都可以感覺到些許Java的味道，特別是在一些架構方面更是清楚的透露了Steve的背景。既然我們瞭解了Steve的背景，那麼當Steve在面臨負責DataSnap的研發方向時你覺得Steve會怎麼做? 因此讓我們試著分解前面的數個問題，:
所以現在很清楚了，Delphi/BCB的DataSnap採用TCP + JSON之後不但提供了更具彈性的分散式架構，而且由於JSON的簡潔，因此在傳遞速度上將會非常的理想， 使用JSON另外一個好處是JSON也定義了傳遞物件的格式，這非常的有趣，因為DataSnap中的DataSet，Delta等都是物件，那麼不是都可以使用JSON來傳遞嗎? 再者遠端物件的方法也可以當成物件來看待，那麼再進一步也許再藉由Delphi/BCB原有的RTTI那麼是不是可以做到像Java的RMI(Remote Method Invocation)呢，我想當時Steve心中一定是這樣想的。如果能夠這樣做到的話，那麼代表Delphi/BCB的用戶端就可以像Java一樣在用戶端呼叫遠端的伺服器服務，再藉由DataSnap原本豐富的DataSet/Delta等處理資料的功能，那麼這將比Java的RMI強太多了。 這樣的思路的確發人省思，因為如此一來不但發展出了DataSnap新的分散式架構，允許Delphi/BCB用戶端不必使用COM/COM+就可以呼叫遠端服務，而且使用JSON之後Delphi/BCB可以立刻整合於Java，Ajax和.NET。 不過要這樣做仍然需要克服2個最大的技術問題，那就是: 1 原本的DataSnap分散式架構使用COM/COM+，用戶端的TClientDataSet等元件是藉由IAppServer介面和遠端的Remote資料模組溝通，因此如果新的DataSnap使用TCP + JSON，那麼舊的DataSnap應用程式怎麼辦? 2. Delphi/BCB原本的RTTI提供的資訊不夠豐富，而Delphi/BCB又沒有像Java/.NET那樣的Reflection API，因此用戶端無法擷取足夠的遠端方法的MetaData進而組合正確方法原型以呼叫遠端的服務方法。 第一個問題不難解決，舊的DataSnap仍然會存在於Tiburon之中(也就是說仍然可以使用COM/COM+)，問題只是在如何通透的讓舊的DataSnap架構能夠使用JSON，其實這個關鍵只是IAppServer介面，因此我們只需要使用Adapter設計樣例就可以簡單的解決，那就是讓DataSnap用戶端連結到新的元件，這個元件同樣實作了IAppServer介面，這可以讓DataSnap用戶端以為仍然是連結到以前的Remote資料模組，但事實上已經是連結到使用TCP + JSON新架構的元件了(就是稍後我們會討論的TDSServer和TDSServerClass元件)。 第二個問題則需要新的編譯器技術，在原本的RTTI中產生足夠的Metadata可以讓DataSnap用戶端呼叫遠端方法，這就是Tiburon新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}的目的。
OK，瞭解這些基本的思路和想法之後，下次就讓我們看看如何在Tiburon中使用TCP + JSON建立一個新的分散式應用程式，同時我們也會觸及到JSON是出現在這個新的分散式架構的那個地方，Have Fun! August 01 Tiburon遊記1看來在CodeGear併入了Embarcardero之後，整個公司的文化似乎瞬間活潑了起來，雖然CodeGear尚未正式宣佈Tiburon的發行日期，但是在CodeGear的部落格中卻出現了大量討論Tiburon的文章，這在以前Borland的時代是不可能發生的，我還記得前幾年我還在Borland工作時，有幾次在部落格中不小心提及了尚未推出的Delphi/C++Builder時就會被老外叮的滿頭包，更別說是像現在CodeGear公開的在部落格中討論尚未推出的Tiburon的各種新功能了，CodeGear似乎已經慢慢的走出Borland時代保守到不行的風格了。 這次的Tiburon應該算是CodeGear對於Delphi Win32以及C++Builder Win32從Delphi 7/C++Builder 5以來最大幅度的進步，Tiburon在每一個領域都有都重大的功能和進步，其中許多新的功能都已經在CodeGear的部落格中有被提及，我在下面的表格中做了大概的整理:
除了上述的功能之外，Tiburon還提供了新的專案管理員，功能更多的除錯器，新的Class Explorer新的DUnit和DBUnit讓Delphi開發人員能夠更有效率的使用TDD。 這次Tiburon對於C/C++的支援也將和Delphi同步推出，再也不落後給Delphi，而且Tiburon新增的C/C++功能絕不遜色於Tiburon For Delphi，事實上這次Tiburon For C/C++進度的幅步似乎比Delphi還好，看來新的C/C++Builder的產品經理雄心是非常的大，下面的表格大致列出了Tiburon For C/C++主要的功能:
當然，Tiburon For C/C++也有新的專案管理員，新的除錯器等，就像Delphi一樣。 例如下圖是Tiburon For C/C++有關建立COM/COM+的精靈，熟悉Delphi 7/C++Builder 5的朋友應該可以看到所有的COM/DCOM/COM+精靈都回到Tiburon中了，而且Tiburon支援最新的COM/COM+標準。
而下圖則是Tiburon For C/C++全新的Pre-compiler header精靈，它能夠分析開發人員的C/C++專案中的原始程式並且建立新的Pre-compiled header，讓中/大型的C/C++Builder專案的編譯速度大幅加快。
Tiburon這個版本不但實用而且提供了最先進的Win32開發能力，如果您目前還需要進行Win32的開發，那麼您的確應該好好考慮Tiburon，雖然目前Tiburon還在Beta，但是它非常的穩定，在最近的幾個Beta版中我並沒有沒有碰到任何的問題。 Tiburon提供了許多的新功能，但是我對其中的JSON分散式架構非常的有興趣，因為Steve自從RAD Studio 2007以來就是最有創意和開發能力的領導人之一，在下次的文章中讓我們看看什麼是JSON分散式架構，它和原有的DataSnap架構又有什麼關係。 Have Fun!
|
|
|
