【www.bbyears.com--Delphi】
摘要：为什么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。