为什么创建VCL for .NET？

摘要：为什么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平台上进行开发，同时只需最少的时间损失来使用新的工具与再学习。