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的目的是什麽？它是一個短期的移植橋梁還是一個長期的應用框架。爲什麽Borland要創建這些東西來和微軟的WinForms競爭？這是明智之舉還是缺乏謹慎？ 安靜一下吧，沒有必要再爲這個問題爭論不休了，真的。原因如下。 背景 微軟的.NET框架提供了一個硬體中立的執行環境和語言無關的類型系統。這很好，但是要産生基于Windows作業系統的用戶端應用程式還不够。.NET還包括了Windows表單（"WinForms"）應用框架來爲WIN32作業系統創建圖形介面應用程式。熟悉在Delphi或C Builder中的 Borland VCL應用程式架構的程式師們將會在.NET的WinForms框架中找到許多曾經相識的設計模式。這幷不很奇怪：就像Anders Hejlsberg所說的那樣，“是好機制那爲何不用呢”。 雖然VCL與WinForms之間有很多相似之處，但實質上要移植現有的Win32 VCL應用程式到WinForms上是非常困難的，也是很痛苦的。而且這將限制采納新的思路。相應的（軟體）工具的銷售也會帶來同樣的問題。 .NET是一個新的平臺。在軟體行業中，甚至所有新的活動都基于.NET，相對于現存的和正在進行的Win32開發而言，.NET應用程式開發仍只是很小的一部分。我們早些時候關于客戶對于.NET平臺興趣的調查，非常清楚地表明，許多Borland客戶對于.NET是一種不確定的興趣，他們承擔不起放弃在Win32平臺上的所有投資的代價，而完全在新的.NET平臺上從頭開始。今天仍然如此，而且這種情形還將持續多年。 在Delphi 8 for .NET中創建一個WinForms是輕而易舉的。現有的Delphi開發者們告訴我們：“這很好，但是我們能用它來爲我們的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視窗控制碼，它們勾住Win32的WndProc函數來偵聽視窗消息，幷且在類中觸發相應的事件，等等，等等。 它們的工作原理就像VCL一樣 如果在被托管的.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實現了針對筆，刷子，以及設備上下文的控制碼共用，而WinForms沒有。微調與探索這些性能方面的機會是Delphi開發小組持續的任務，就像微調WinFrorms的性能與.NET的性能是微軟持續的任務一樣。 VCL已經被證明可以適應于平臺的變化—從16位Windows到32位的Win95，從NT到在Linux上基于QT的CLX。WinForms與.NET緊緊地捆綁在一起，而且在很大程度上與Win32捆綁在一起。 說明: 雖然.NET精簡框架實現了WinForms命名空間中的許多類，在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作業系統的下一個主要發布版本中將有重大的改變。很清楚，代號爲“長角”的微軟作業系統將會同時有介面表示與下層實現的重大轉變。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表單應用架構是完全（由微軟--譯注）有意確立的一種合理的架構，然而采用WinForms的代價是昂貴的，因爲它不能把現有的源代碼移植上去。 Borland的VCL for .NET架構爲Delphi開發者提供了最好的兩個方面：它可以讓你利用現有的源代碼和開發經驗在一個新的正在壯大的.NET平臺上進行開發，同時只需最少的時間損失來使用新的工具與再學習。 Danny Thorpe Delphi編譯器架構師,.NET團隊負責人 開發者工具集團 Borland軟體公司 -------------------------------------------------------------------------------- 翻譯說明:本文原文爲2004年2月23日發表在BDN上的Why VCL for .NET。本文翻譯完畢日期爲2004年3月9日。若轉載，請注明作者與譯者，以及出處 http://www.delphidevelopers.com/borland/Borland_Danny_Thorpe_VCL_DotNet.htm 。本文在CSDN上的鏡像在這裏 。 www.delphidevelopers.com 原始資料來源:http://www.csdn.net/Develop/article/25/25418.shtm