科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件苛评VCL: 臃肿的Windows控件

苛评VCL: 臃肿的Windows控件

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

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

作者:韩小明 来源:CSDN 2008年2月4日

关键字: 控件 Windows Linux

  • 评论
  • 分享微博
  • 分享邮件

我们知道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控件封装是非常好的设计。只是我想问问,是不是有更好的设计呢? 


查看本文来源
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章