Borland 為什麼研發VCL for .NET？ Why VCL for .NET 作者：Danny Thorpe 翻譯：Bear 摘要：為什麼Borland 研發VCL for .NET？什麼時候您該使用VCL for .NET而不是 .NET系統本身的Windows Forms框架？ Delphi 8 for .NET在Delphi社群中引起了極大的關注！人們在新聞群組，聊天室，以及用戶間小型聚會中頻繁地討論著 .NET 基礎架構，談論著此架構與我們都熟悉的 Win32平臺間之關係。 其中一個熱門話題便是Delphi8的VCL for .NET。大部分爭論似乎都集中在這個問題上：規模龐大的 VCL for .NET 其目的是什麼？它是一個暫時、移植用的橋樑；還是一個長期之應用框架 ( application framework )。為什麼Borland要研發這此框架來和微軟的 WinForms競爭？這是明智之舉還是錯誤的決定？ 冷靜一下，沒有必要再為這個問題爭論不休了，真的。原因如下： 背景 微軟的 .NET框架提供了一個硬體中立的執行環境和語言無關的類型系統。這很好，但是要產生以Windows作業系統為基礎的用戶端應用程式並不足夠。因此，.NET提供了Windows Forms應用框架來為WIN32作業系統建立圖形介面之應用程式。熟悉在Delphi或C Builder中的 Borland VCL應用程式架構的程式設計師們將會在 .NET的 WinForms框架中找到許多曾經相識的設計模式。這並不很奇怪；就像Anders Hejlsberg所說的「是好的機制；為何不用呢？」。 雖然VCL與WinForms之間有許多相似之處，但實際上要移植現有的Win32 VCL應用程式到WinForms上是非常困難且痛苦的。而且這將限制必須採納新的思維。連帶將影響了工具的銷售。 .NET是一個新的平臺。在軟體行業中，甚至所有新的研發活動都是基於 .NET，相對於現有與正在進行中的 Win32開發而言，.NET應用程式開發仍只是很小的一部分。我們之前對用戶需求調查非常清楚地顯示， 許多Borland用戶對於 .NET是一種不確定的興趣，他們承擔不起放棄在Win32平臺上的所有投資的代價，而完全在新的.NET平臺上從頭開始。今天仍然如此，而且這種情形還將持續多年。 在Delphi 8 for .NET中使用 WinForms是輕而易舉的。現有的Delphi開發人員告訴我們：“這很好，但是這對我們現有的VCL程式有何助益？這些 VCL 程式碼都是以前開發的，我們的業務都依賴於這些程式碼。” 為了讓我們的客戶滿意度提昇，並且讓 .NET平臺對於現有的Delphi開發者更具吸引力，需要有一些東西來填補現存的 Win32開發與新的 .NET開發之間的鴻溝。它必須如 .NET框架自身一樣；是一個純粹的 .NET，它還需要提供一個與現有Win32 VCL架構間的高度相容性。為了吸引現有的VCL開發人員， Delphi for .NET需要在 .NET平臺上實作一個VCL 框架。 我們首先考慮了在WinForms框架的之上實作VCL。在一些初步研究之後，事情變得很清楚，由於VCL應用程式與 WinForms架構上的差異，使得很難在WinForms框架之上再建造一個VCL層，並且按照VCL的方式工作。 在我們評估WinForms的過程中，我們注意到WinForms其實是建立在Win32 API叫用之上的。WinForms 視窗類別叫用了CreateWindow ( ) 建立Wind32視窗控制碼，它們勾 ( Hook ) 住Win32的WndProc函式來接收視窗訊息，並且在類別中觸發對應的事件，等等。 它們的工作原理就像VCL一樣 如果在被託管 ( Managed Code ) 的 .NET程式碼中呼叫 Win32 API對.NET框架適用，那麼它對VCL也同樣適用。這樣，在.NET平臺上實現VCL的過程；就變成了找出如何進行Win32 API呼叫的方法，這是現有VCL架構所大量使用的技巧，並且在我們可控制的範圍內，也是對VCL自身程式碼修改最少的方法。 VCL for .NET的情況 VCL架構是與微軟的WinForms架構對等的，而VCL for .NET是VCL架構的繼續與演進。WinForms與VCL for .NET都建立在對Win32 API的叫用之上，所以有相似的平臺約束與相似的執行特徵。對於VCL而言，甚至還有潛在的機會能比WinForms運行得更出色，這是因為VCL實作了針對筆 ( Pen )，刷子 ( Brush )，以及設備上下文的控制碼共用，而WinForms沒有。微調與強化效能是Delphi開發小組持續的任務，就像微調WinFrorms的效能與 .NET的效能是微軟持續的任務一樣。 VCL已經被證明可以適應於平臺的變化 — 從16位Windows到32位的Win95，從NT到在Linux上以QT 為基礎的CLX。而 WinForms與.NET緊緊地綁在一起，而且在很大程度上與Win32 綁在一起。 說明: 雖然.NET精簡框架 ( Compact Framework，以下簡稱 CF ) 實作了WinForms命名空間 ( Name Space ) 中的許多類別，在CF上還是有許多東西是不同的或遺漏了。我不認為CF WinForm與Win32 WinForms是相容的。微軟顯然承認這一點，因為他們讓 .NET CF執行環境與Win32 .NET的執行程式在二進制層級上就不相容。.NET CF系統的assembly與Win32 .NET系統的assembly是不同的，因此 Win32 .NET執行程式將會在CF設備上裝載失敗。唯一的進入 .NET CF的方法是把程式碼在CF上重新編譯，並且與CF的assembly鏈結起來。 對於應用程式碼而言，從Win32 VCL移植到VCL for .NET是相當簡單的，但對於那些與Win32 API關係密切的元件而言，可能需要花費多點工作。這與移植到CLX的情況很相似。然而，Delphi開發者會發現，從Win32 VCL移植到VCL for .NET所需的心力；要比從Win32 VCL移植到CLX所需的心力更少。VCL for .NET在很大程度上改變了執行環境，但實現了與Win32 VCL幾乎相似的訊息處理，異常處理，以及Win32 API支援。而CLX為了在Linux平臺上運行不得不犧牲訊息處理與Win32 API支援。 VCL for .NET的代碼移植並不是單向的。為VCL for .NET 編寫的應用程式碼也能在一個合理的範圍內反過來被移植到Win32 VCL上。再次地，要維護跨平臺的同一份原始程式碼，那些與Win32叫用很密切之程式碼（如自訂之控制項），要比移植一般Delphi語法編寫的應用程式邏輯會更困難一些。 用C#來編寫應用程式就要讓開發者們完全拋棄他們現有的程式碼與開發經驗，在.NET中從頭學起。C#把開發者完全限定在鎖定的.NET平臺上。在其他平臺上並沒有C# 的實作版本。（是的，在Linux上有Mono，但它並沒有實作UI/WinForms 部分，因此它並不是一個完全的用戶端應用程式開發的解決方案。） VB.NET幾乎處於同樣的處境，因為VB.NET用戶痛苦地抱怨VB.NET與VB連基本語法都不相容，這使得在VB.NET與VB之間移植程式碼比完全重寫還要冒險。 用Delphi語言為 .NET平臺編寫程式還提供了將程式碼移植到其他非 .NET平臺 （例如 Windows與Linux）上的機會。用VCL for .NET來編寫應用程式提供了任何其他 .NET語言都沒有的移植選項。 VCL for .NET是為Delphi程式設計師而存在的 VCL結構依賴於Delphi語言的幾種強勁特性，這幾種特性在其他 .NET語言（包括C#）中是沒有的。然而，我並不期望 C# 或者VB程式設計師對 VCL for .NET有濃厚興趣。C# 程式碼可以利用VCL for .NET元件，但VCL的某些方面（比如虛擬構造器）在C# 中是難以使用的。 用VCL for .NET實作的GUI控制項只有Delphi程式設計師感興趣， C# 或VB.NET程式設計師沒有多大興趣。 只要Delphi開發人員保持這樣一種觀念，即某些獨特的Delphi語法，並不能被C# 或者其他 .NET程式設計師很容易地理解，如虛擬類方法，虛擬構造器，集合，標準化字串，以及類別引用，但是其他方面，如非視覺化元件，公用類別，商業邏輯都能用Delphi實現並且被C# 或VB.NET程式師方便地使用，在VCL for .NET表單上能放置WinForms控制項。Delphi開發者編寫的VCL for .NET應用程式能同時使用VCL for .NET元件與控制項，就像使用任何WinForms元件與控制項一樣。 也許比實際的原始程式碼更重要的是開發人員之開發技能。對VCL熟悉的開發人員立即就能熟悉 VCL for .NET。在Win32 VCL中您怎樣建立一個應用程式，怎樣建立一個客制化元件，或怎樣建立客制化訊息處理，在VCL for .NET中您就怎樣建立，兩者的方式是完全一樣的。VCL for .NET讓熟練的Delphi開發者能在.NET平臺上立即具備豐富之生產力，而避免花費三到六個月的額外時間；為了不同的應用框架架構而對開發人員重新進行教育訓練。 Delphi語言是獨立於VCL的 VCL for .NET依賴於Delphi語言的一些特性，但Delphi語言本身並不需要VCL。您能直接用Delphi語法編寫WinForms應用程式，而不必將VCL for .NET拖入您的應用程式裏。您也能用您熟悉的Delphi RTL工具函數與類來編寫WinForms應用程式，這樣的好處就是，例如，您不必花時間來找在 .NET中與Delphi的IntToStr ( ) 對應的函式是什麼。 每一種程式語言都必須定義如何將語言特性與下層平臺可用的架構結合起來。在.NET中，這種下層架構包括核心語言類型這類程式碼。Delphi語言擁有CLR沒有實作的概念與語法，所以Delphi在語言上需要一些程式碼來補足CLR沒有提供的部分。這種語言特色可能被直接聯接到您的Delphi應用程式的exe或者assembly中，或者您也可以聯接一個外部的叫做Borland.Delphi.dll的assembly (pacage)。 每一種 .NET語言都有一個語言專屬的函式庫。VB.NET的Microsoft.VisualBasic.dll大小大約為300K。JScript的Microsoft.JScript.dll大小約為700K。C# 的語言專屬的函式庫大小大約為3到20MB，這視您是否把mscorlib.dll 與System.dll也考慮進去，或者計算所有的C# 需要的 .NET框架。而Delphi的Borland.Delphi.dll在大小上小於64K。 無論是投資到VCL原始程式碼與開發者技巧（使用VCL for .NET）的人們，還是那些願意從頭開始學習如何在.NET平臺執行專案（使用WinForms）的人們，Delphi for .NET都會引起他們的興趣。 未雨綢繆 在微軟的長期平臺/作業系統產品策略中，已暗示了在Windows作業系統的下一個主要發佈版本中將有重大的改變。很清楚，代號為 “長角” ( Long Horn) 的微軟作業系統將會同時有操作介面與底層實作的重大轉變。Win32 API將會變成在現有Win32程式與實際的OS表示層之間的一個相容的層。微軟已經為長角作業系統建立了一個新的應用框架（“Avalon”）。您可以在MSDN上讀到更多的關於該框架的資訊。 改變很多時候會引起驚慌。所以很高興從微軟處得知WinForms應用程式可以繼續在長角及其後續版本上使用。VCL for .NET是建立在與WinForms相同的基礎上的，所以VCL for .NET應用程式應該也可以繼續在長角及其後續版本上運行。VCL已經通過了幾次平臺移植的考驗（從Win16到Win32，從Win32到Linux，現在又從Win32到.NET），這比WinForms所經歷過的還多，所以有理由認為VCL fot .NET比WinForms更容易適應在長角作業系統中所面臨的改變。 所有這些加起來使得VCL for .NET成為一個比WinForms架構更強大體系。對於現存的VCL應用程式而言，比起為WinForm而重寫程式碼的這種方式，VCL for .NET具有更長的可用生命週期，而不是作為一個臨時的單向過渡方案，而且還有更好的投資報酬率（ROI）。 為什麼要改寫您的應用程式？把您現有的VCL應用程式移植到VCL for .NET可以以更少的努力獲得同樣的結果。即使VCL for .NET與WinForms在同一條船上翻掉，VCL for .NET也意味著比WinForms有更好的投資回報。 這就為什麼我們建立VCL for .NET的原因。 結論 對於新的應用程式開發而言，採用微軟的 .NET平臺 Windows Forms是標準且合理架構，然而採用WinForms的代價是昂貴的，因為它不能把現有的程式碼移植上去。 Borland的VCL for .NET架構為Delphi開發人員提供了最好的選擇：它可以讓您利用現有的程式碼和開發經驗在一個新的、正在壯大的 .NET平臺上進行開發，同時只需最少的時間來學習使用新的工具。 Danny Thorpe Delphi編譯器架構師,.NET團隊負責人 Developer Tools Business Unit Borland軟體公司