为什么选择Delphi.Net
为什么选择 ？作者:Chad Z. Hower 译者:Bear
许多人曾预言，随着.Net的引入，从一种语言的角度来说，Delphi将会衰落或者消亡。在过去的几年里这种预言就已出现很多次了，然而Delphi仍然保持了稳定的发展，甚至还有几次斩获。我相信随着.Net的持续增长，Delphi将不仅会保留住它的拥护者，而且其使用与拥护者都会增加。这是与今天许多人的意见相反的，下面我将解释这一点。
谁将从.Net获益？
.Net是个好东西。但是.Net所提供的大部分东西只是对程序员有好处。除了程序员利用.Net提供的东西外，最终用户只能获得极少的好处。没有最终用户会重启他们的计算机，并说“是的，我想今天我将安装.Net”。用户将只在被.Net应用程序要求的时候去安装.Net。
就个人而言，.Net对我最大的吸引力就是我们最终拥有了代码的跨语言兼容性。这已被延误很久了，但是跨语言兼容性也仅是程序员的工具。最终用户不会关心C#代码是否能与Delphi一起工作的很好。最终用户只关心这个程序是否做了他们希望它做的。
.Net是为服务器的
在你反驳我之前，这条申明从来都不是真的。.Net当然不是只为服务器设计的。.Net也是为桌面计算机设计的，然而从相近的术语上层面上说，.Net是为服务器设计的，这就是为什么.Net现在是并且将来也是被用作这种相近术语的原因。在一个机器上安装.Net，1.0版本需要20M以上的空间，1.1版本已发布，体积更大（1.1版为23M，并且最终的安装需要110M）。这仅仅是在安装方面，除了体积大以外，它还将变成操作系统的一个核心部分。
对于那些安装大小不是个问题的用户来说，部署与支持却也是个问题。对于有着成百上千的计算机的那些公司来说，不会简单地大规模部署任何软件系统，当然也不会不做许多准备工作就贸然安装像.Net这样的核心软件。
对于家庭用户来说，就不仅仅是安装问题了，还有带宽的问题。软件当然还是通过CD来发布的，但大多数家庭用户使用的非游戏软件都是从因特网直接下载的。当然许多用户今天也拥有宽带接入，但是除去程序员以外，大部分家庭用户都没有宽带接入。多数可下载的程序都在1-5M之间，这是一个可以接受的下载大小。把体积增大到5-20倍那就不太好下载了。
一旦你安装了它，它就在那儿了
是，又不是。一旦你安装了.Net，事实上你就拥有它了，并且对于所有.Net程序来说，它都是可用的。然而，.Net框架1.1版本已经发布，显然1.2或者2.0也已在开发之中。以前的经验告诉我们每一个版本都会比老版本体积大。如果一个用户已经安装了1.0，但是你的程序又需要1.1，这个最终用户就需要另外的更大的安装。最后，完全可以想象最终用户将需要多达4个不同的.Net框架版本，来支持已安装的软件。
程序员的观点
.Net很酷。.Net很新。这就足够让大多数程序员期望.Net了。当然，.Net也确实有足够的真材实料来让自己值得程序员的期望。不过，我们还是从不同语言的角度来看一下吧：
C++ - 简言之，C++是不能被托管的代码，这样就不能在.Net上很好的工作。C++用户将被划归到非托管代码或者设备驱动开发这一类中去。微软已经在鼓励C++开发者转移到C#了，并且最后非托管代码将不只是不被鼓励，而是几乎就是不被允许了。虽然C#在很多方面与C++都相似，而且显然(其语法)根植于C++，但是仍与C++有着很大的差异。多数C++开发者都是纯粹主义者，对他们的语言有着非常狂热的执著。由于这一点，许多C++开发者都不喜欢C#，并且根本不情愿转移到C#上去。
Visual Basic - Visual Basic 在.Net中并不存在，而是变成了Visual 。与VB是不兼容的，仅仅在一些基本语法上有些类似。（在.Net上）VB程序必须被重写，而且几乎是完全重写。当VB最终有了一些改变来使它成为一个“真正的”语言时，VB用户却开始反对了。许多VB用户很不满意地称为Visual Fred，而且誓不转移到.Net平台，或者干脆就投奔Delphi。
Delphi - Delphi 7用户已经有了一个Delphi for .Net编译器DCCIL的预览版。Delphi 8 将提供完整的Delphi for .Net编译器。现有的Delphi代码，当然需要一点改变，将能被轻松地移植到.Net平台。
这意味着什么？这意味着Delphi将是移植到.Net的路径中代价最小的一条。如果你是一个Delphi开发商，你知道你就能以最小的顾虑而转移到.Net上，然而如果你是一个Microsoft开发商，你就要选择是完全重建还是维护两套不同语言的系统，两种选择都很拖累。也就是说是继续维持现有的VB或C++的系统呢，还是重新以C#或则建造新的系统。
.Net需要两次开发
由于语言兼容性问题，.Net基本上是个比较极端的事情。由于很可能众多公司将只在服务器而不是桌面计算机上部署.Net，因为现存的应用将很可能不被移植到.Net上，开发者们必须以两种语言开发，一种是VB 或 C++,另一种是 C# 或 。除了开发人员必须被培训两次外，还必须为可预见的将来保持分开的不兼容的两份代码库。
很少开发商能为使用了.Net的最终用户而完全转移到.Net上来，即使他们可以，也不得不支持老的应用或为移植问题而重写代码。
在另一方面，Delphi允许开发者只维护一份通用的代码库，就能被用作在Win32 (不是 .Net) 与 .Net上跨平台部署。Delphi也能让开发者通过Kylix（重新编译源代码）而在Linux上部署应用。对现有的Delphi开发商而言，只需要对开发人员进行很少的再培训。
可是现在并没有
现在并没有Delphi for .Net，但许多开发者已看到这种趋势了。在Delphi 8中的Delphi for .Net将提供独一无二的跨平台选择与简单容易的移植路径。在预料到这一点之后，许多开发者正在转向Delphi。
.Net开启了大门
由于现存的库，代码与第三方支持（有许多是非Delphi语言的），语言互操作性的缺乏曾经阻止了许多开发者使用Delphi。有了.Net，语言就不再是个问题。.Net将使更多的开发者转移到Delphi上来。（这里所谓更多的）开发者就是那些以前曾经考虑过Delphi，但由于这个约束而没有转移过来的开发者。
Delphi 8 冲击
作为一个组件供应商，我们可以研究我们自己的客户。虽然Delphi7是一个成功的产品，但许多用户还仍然在使用Delphi5与Delphi6。这些用户只是仅仅没有看到任何使用Delphi7的需要而已。然而，带有.Net支持的Delphi8将给他们提供一个非常强大的升级动机，现在许多这类用户正在等待着Delphi8的问世。就我看来，Delphi8将是一次非常成功的发布版本，将不只是Delphi7用户的升级目标，也将是许多Delphi5与Delphi6用户的期望之选。
结论
我恨.Net吗？不，恰恰相反。但是，转移到.Net也不是一蹴而就的，而且还要付出一些代价。Delphi提供了最佳的移植路径，特别是在.Net普及后，其优点更是意义重大。所有这些因素都将让Delphi 8获得巨大成功，并且推动Delphi被更多地使用。
--------------------------------------------------------------------------------
作者简介: Chad Z. Hower是Delphi组件集Indy的原始作者，组件集IntraWeb的作者，AToZed公司创始人，常去世界各地游历。
译注：原文发表日期为2003年9月11日，本文在征得作者同意后翻译，翻译完毕日期2003年9月17日。转载请注明出处：www.，并保留作者译者名称。
