苛评VCL: 臃肿的Windows控件

写这一篇还是顶着很大的压力的。相信又有不少人要瞧不过去了。不过本着讲讲设计，无所谓好和坏，只有较好和较坏的差别。我只是从我的角度，尽量去解释为什么不赞同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控件封装是非常好的设计。只是我想问问，是不是有更好的设计呢？