写这一篇还是顶着很大的压力的。相信又有不少人要瞧不过去了。不过本着讲讲设计，无所谓好和坏，只有较好和较坏的差别。我只是从我的角度，尽量去解释为什么不赞同VCL中的设计而已。

我们知道VCL封装了Windows的标准控件。这些控件包括：Edit、ListBox、ComoBox。还有一些Win32控件，包括ListView、TreeView等等控件。

所有这些，在VCL中定义为TWinControl，他们都包含Windows分配的句柄Handle。也有自己的绘画句柄HDC，当然了，在VCL中就是Canvas属性。我们现在开始说明VCL是如何实现这些控件的。

正如前面所说的，与其说是实现这些控件，更不如说是“封装”这些控件。因为VCL在实现这些控件的时候，采取的是适配器(Adapter)模式。为什么这么说呢？

Windows已经实现了这些控件的数据存储和界面显示两部分。可是VCL又想将这些现成的实现，融入到VCL架构中。这个时候，使用Adapter模式是最适合的了。当然了，这个适配的过程是艰辛和具有创造性的。

我记得刚学习Delphi的时候有人对比MFC的控件的时候，说Delphi将控件的显示和数据做在了一起，而MFC不是。将程序使用MVC来分层分析，当然是一种办法。但是同样可以使用组件来分析。在面向对象系统中，组件即对象。所以VCL将整个控件的数据和显示封装在一起，也是有一定道理的。

最近和同事们也讨论过VCL的这个架构。在Borland看来，这个选择应该是非常明智的。在我看来，至少有几个理由：

1. 充分利用了Windows这方面的实现和标准。
2. 让Delphi编出来的程序接近于Windows的标准。
3. RAD的需求，所以数据和显示在一起。而没有分开实现。
4. 控件风格可以和Windows一致，而不需要额外实现。

可是，这一层Adapter，随着Delphi的发展壮大，已经慢慢成为VCL中的负担。而且由于Office界面标准的流行，控件的标准已经不在Windows手上了，虽然同样是一个公司的。我认为也正是因为这个原因，Windows在Xp和Vista中对控件的风格重新定义了一遍。这里面的关键在于，标准在谁手里。只要当你的使用量超过一定的时候，你就可以也应该有自己的标准了。

而且，这些控件也正在逐渐显示出一些弊端：

• 数据量增大的时候，数据存储不能适应。
• 当消息队列被破坏的时候，使用消息队列控制创建和释放的数据也会受到影响。要知道，消息队列有一个特点，那就是存在失去消息的风险。

我们是不是可以假设存在一个这样的设计：数据的存储由VCL自行实现，而显示则调用Windows的实现。这是一个封装在一起的分层(MVC)实现架构。这个架构的一些好处是：

1. 数据的存储不需要通过Message的方式。效率可以得到极大的提升。特别是当应用中的数据量剧增的时候。
2. 风格同样可以使用Windows的标准显示。
3. 对象实例的控制完全使用Delphi的原生方式，简单而有效。
4. 界面的绘制，可以增加自行定义的方式。以目前注重体验的界面风格，是非常重要的。

如果我们以后可以将界面显示做成框架支持，都可以在编程中，将控件作为业务实体来使用，这就省去了我们现在经常要做的一件工作：完成实体对象和界面对象的相互转换。当然了，这些是后话了。不过很多公司愿意自己定义控件的存储，就是基于这个需求。

VCL中的Windows控件封装是非常好的设计。只是我想问问，是不是有更好的设计呢？ 

评论

#   ThenLong 发表于2007-02-06 10:54:34  IP: 218.94.36.*

borland是为解决80%-90%的开发问题 你这样的需求不是那么容易解决的 我曾经都想做一些c/s的erp或者简单的信息管理系统的框架 结果发现非常难，呵呵 工作量无比巨大是一个方面 结构方面的设计和架构也是很难。。。

#   xikug 发表于2007-02-06 13:43:35  IP:

博主就是一明显不懂OO, 不懂delphi，不懂VCL的大傻帽。。。 哗众取宠。。。

#   xikug 发表于2007-02-06 13:46:09  IP: 58.33.209.*

博主同样不懂设计模式。。。

#   mhmdanger 发表于2007-02-06 14:57:39  IP: 222.209.106.*

博主还是有些能耐的，您什么时候能够站出来分析说unix系统设计得太差了就好了，如果分析时能够指出一些改进方案的话，说不一定还能得到什么计算机大奖

#   THXK 发表于2007-02-06 14:59:33  IP: 61.140.34.*

连续看了,这位仁兄的几篇文章,就算这篇看懂仁兄的意思,其实只是思路不一样,如果BORLAND像JAVA样整个swing,情形将会怎么样??当然BORLAND的CLX实现的VCL已经不是WINDOWS的了 还好,BORLAND的标准控件还不算臃肿的,主要是以DEVEXPRESS为首的三方控件太变态,现在开避了个.NET新战场, 我不个不喜欢花花绿绿的界面,开发从来不用什么皮肤控制,OFFICE XP,2003 .NET的效果看久了真是视觉疲劳,

#   zhouhongyun 发表于2007-02-06 15:39:43  IP: 219.140.59.*

刚学编程的人很喜欢在界面上下功夫，达到一种境界了就不会了

#   zwjchina 发表于2007-02-06 21:56:35  IP: 202.105.139.*

那么 MFC 又何如？ MFC 的 View-Document看似不错， 但是即使一个按钮的MouseMove的处理都不得不继承一个。 并且处理逻辑很难与纯界面分离。

#   onemonth 发表于2007-02-07 09:45:36  IP: 222.183.19.*

楼主的题目有哗众取宠的嫌疑：你只是说了一句，“随着Delphi的发展壮大，已经慢慢成为VCL中的负担”，但是没有在任何地方解释那里臃肿了。 我们看看你说的坏处： 1、数据量增大的时候，数据存储不能适应。 既然是标准的windows控件，谁让你背离标准呢？这个与vcl无关。 2、 当消息队列被破坏的时候，使用消息队列控制创建和释放的数据也会受到影响。要知道，消息队列有一个特点，那就是存在失去消息的风险。 我只能说这个提法相当荒谬。那么我问你，如果vcl自己实现存储，你是不是又会说，当存储区被破坏时，又怎样怎样呢？搞笑！ 最后，当我看到楼主所说：“如果我们以后可以将界面显示做成框架支持，都可以在编程中，将控件作为业务实体来使用”，我明白了楼主的水准了。奉劝一句，这样的水平，你可以用日记的方式，自己写给自己看，不要在blog上一本正经的讨论别人的构架设计了，很丢人的。

#   Could 发表于2007-02-07 09:47:23  IP: 58.49.83.*

vcl本来就是臃肿不堪

#   yrb 发表于2007-02-07 09:51:26  IP: 60.31.80.*

是不是失业了，怎么总是哗众取宠？？

#   yrb 发表于2007-02-07 09:54:29  IP: 60.31.80.*

写一个出来，让大家也开开眼。

#   baiduan 发表于2007-02-07 10:38:04  IP: 218.107.130.*

引用： 所以VCL将整个控件的数据和显示封装在一起，也是有一定道理的。 数据量增大的时候，数据存储不能适应。 =================================== 我日，这话也说的出口？你去看看vcl源代码在说话吧。 人家提供了方法，你自己不会用就不要jjyy。 基本的东西都不会还奢谈架构？肯定是一个GetMem,FreeMem都不会的笨蛋，月薪不超过4000的猪头。

#   Rural_Boy 发表于2007-05-02 14:25:06  IP: 125.92.199.*

怎么看,这篇文章给人的感觉总是 标题 和 内容不符的一样. 我没什么要说的,仅仅是针对 博主 的一个观点说一句: 将界面显示与数据保存分开.但这可能实现吗?可以,但是需要多少额外的代码呢?你知道 TListBox 是依赖控件本身保存的 PChar 数据来决定如何显示界面的,那么你想到了什么方法来解决你所谓的"界面与数据分开"的想法呢? TlistBoxString 是通过发送消息将数据传递给 TListBox 自己保存的,不是封装代码中用变量保存的,我想这你是知道的! 另外,如果是我误解了你的想法,那么如果你的想法是完全自己制作控件.那么所有的标准控件都从 TWincontrol 继承,然后自己实现显示和数据保存.这是可行的,但这需要太多太多的代码了.本人以前为了解决标准 TlistBox 的滑动条界面问题,自己完全重写了一个 Tlistbox,但控件完成之后,一看居然写了几千行代码. 这个控件在这个地方,你可以看看:http://www.2ccc.com/article.asp?articleid=3493

来自：http://blog.csdn.net/xiammy/archive/2007/02/06/1502987.aspx

分类： Borland技术 windows开发 开发工具