Delphi断想

核心提示： Delphi断想 荣耀 2002秋Delphi是迄今为止口碑最好的RAD（Rapid application Development）产品，Delphi 3.0是Delphi系列中划时代的版本，Delphi断想，成熟稳定的Delphi 5.0更加巩固了Delphi企业级开发工具的领先地位，Delphi 4.0是印象

 

Delphi断想

荣耀  2002秋

Delphi是迄今为止口碑最好的RAD（Rapid application Development）产品。

Delphi 3.0是Delphi系列中划时代的版本，成熟稳定的Delphi 5.0更加巩固了Delphi企业级开发工具的领先地位。

Delphi 4.0是印象中最恶劣的一个版本。打了这个补丁，那个程序无法正常编译；打了那个补丁，这个程序无法正常编译。当然了，Delphi不会存在明显的bug的，除非你的程序规模足够大，复杂度足够高。

对于企业软件开发人员来说，Delphi的MIDAS技术具有划时代的意义。在今天微软.NET中，仍然可以看到它的影子。

Delphi的Active Form是一项令人大开眼界的技术。它的优点是，你无需什么特别的Web知识，就很容易将现有Windows项目包装为Active Form，只需添加短短几行代码，即可将其展现于浏览器之中。进入了IE，也就免去了客户端维护成本。这种技术的表现力也远比asp丰富。但它也有一个致命的缺点：它太笨重了，只适合运行在高速局域网里。

在电力系统中普及面较广的财务软件，就是采用这种技术。没有最好的技术，只有最合适的技术，Delphi的Active Form技术用在这种地方，再合适也不过。

要想把这种技术用在广域网中，或者低速局域网内，那简直是一种恶梦。

Object Pascal是我所喜欢的最优雅的语言之一。既传统，又现代；既简单清晰，又功能强大；代码可读性好，又不象Visual Basic程序看起来那么呆板。更重要的是，类似于C++，它也支持多种程序设计风格。

三年前，如果你开发数据库相关软件，但又不想使用脚本性的语言，或者什么专用的开发工具（比如Oracle公司的Developer 2000），你希望使用一种由真正面向对象语言所驱动的开发工具，那Delphi就是最佳选择。

Delphi的设计者意识到了绝大部分软件都要和数据库打交道，从而加入了对数据库相关开发功能的强力支持，这种决策是极其明智的。正是这种对数据库开发的强力支持，导致Delphi取得了巨大的成功。

Delphi对数据库的强力支持，达到、甚至超过了一些专门的数据库开发工具。但这也容易让一些外行误解，以为Delphi只是一种数据库开发工具。

我还记得几年前，南京新街口新华书店里赫然摆放着一本书，它有一个很搞笑的名字：《关系型数据库：Delphi》（记不太清楚了，但大差不差）。

Borland似乎过于注重IDE（Intergrated Development Environment）的功能开发了，它本来可以进一步改善Object Pascal语言质量，一些本该出现于Object Pascal中的语言特性，现在进入了C#，个中原因，无需赘言。

Delphi并没有包装所有的Windows API，比如某些COM相关的API，这也是我放弃Delphi的原因之一。

RAD开发环境，对于企业级项目软件开发来说，绝对不可或缺。RAD降低了软件开发的门槛，RAD也“造就”了一大批半调子程序员。我怀疑对RAD工具的误解和偏见，就起因于这些半调子程序员。

最新版本的Delphi，总是会带来一些最新的技术，有时这些技术对于微软来说还只是一个概念，而Borland已经把它变成了产品。但Delphi的最新技术，有时只能算是一种过渡性的技术。

尽管Delphi 6.0对数据存取、Web、xml都有大力改善和支持，但在我看来，Delphi 6.0不过是一个过渡版本而已。

Delphi的BDE（Borland Database Engine）数据存取技术，提供了对ODBC数据源的完整支持，又打击了ODBC，这种技术在Delphi 3.0中达到巅峰。Delphi的MIDAS技术，提供了n-tier数据存取技术，但仍然建立于BDE之上。Delphi 5.0提供了对ADO的完整支持，并有放弃BDE的架势。Delphi 6.0的dbExPRess和DataSnap技术是Borland对数据存取技术不断创新的又一个例证。

但是，即使在BDE达到鼎盛时期，即使在今天有了那么多数据库存取技术，潮起潮落，ODBC的地位，仍然不可代替。除了直接调用数据库专用API（比如Oracle的OO4O）外，还没有哪一种数据存取技术的效率，可以达到或者接近ODBC API。

微软就是Windows平台上事实上的标准，遗留代码（legacy code）的强大势力往往也超出任何人的想像。

VCL（Visual Component Library）控件和ActiveX控件完全是两码事。ActiveX控件目标于跨语言的二进制重用，而VCL控件则目标于Borland开发环境内的组件重用，重用的层面可以是目标文件，也可以是源代码，这其实更象C++的类重用，比如说MFC（Microsoft Foundation Classes）的类重用。

用惯了VCL控件的程序员，对于需要单独发布、注册ActiveX控件感到厌烦；用惯了ActiveX控件的人，对于Delphi把什么东西都编译到一个大文件里感到好笑。

Delphi的运行时BPL（Borland package library），其实就是一种特殊的DLL，你可以认为它们是Borland格式的DLL。如果你想让程序尺寸变小，如果你同时要发布数个使用了同样BPL的程序，使用运行时BPL，它可以使你心想事成。

Delphi对于版本自动增加功能的方便支持，使得Delphi程序员对于Visual C++需要手工修改版本号，感到奇怪。RAD和非RAD的差异，由此可见一斑。

Delphi模式被成功地克隆到了C++Builder身上，但直到目前为止，C++Builder中的技术，一般仍或多或少地滞后于Delphi中的最新版本的技术，但愿这种状况能够尽快得到改善。

Delphi和C++Builder使用了同样的后端，但Borland没有从一开始就把这两种语言集成到一个Studio之类的集成开发环境之中，从而可以同样的风格（乃至功能）的IDE支持不同口味的语言为促销卖点，这让我不解。我怀疑这要么是一个决策失误，要么暗示了Borland缺乏足够的资源。

对于那些从事企业软件开发同时又迷恋C++的程序员来说，C++Builder无疑是他们的宠儿:)

如果你是一名Delphi程序员，如果你熟悉C#，你就会明白，除了C#采用了C/C++风格的语法之外，并且，撇开许多人都说C#是java的克隆不谈，C#从Delphi中，借鉴了大量的语言设计思想。

我相信，Anders Hejlsberg在设计C#语言时，首先会本能地想到Object Pascal，而不是Java。看看C#的单实现、多接口继承的面向对象的实现；看看try/catch/finally异常处理结构（我知道很多人会说，这些都来源于Java）；看看属性（propery）的概念（我知道有人会说，这来源于Visual Basic）；看看那个override关键字…… 几乎可以断定，这一切首先都来源于Object Pascal。

毋庸置疑，Delphi必须支持.NET。

在.NET平台开发工具领域能够同微软Visual Studio .NET一较高下的，目前也只有Delphi具有这个实力。

在Windows平台上，总有人不喜欢微软，但这些人中的大部分还是要前进到.NET，Delphi .NET就是一个理想的替代品。

Delphi .NET，令人期待。