Access 类模块和开发框架(翻译+改编)系列之二——简介

当你使用任何编程语言编写一个应用程序的时候,在你编写的应用程序中,总会存在某些代码片段,它们除了能作用于当前编写的应用程序外,还能用于其他的应用程序上。

软件行业从诞生的第一天开始,主要关注的问题就是“代码重用”。所以程序员一直被教导,去设计“可重用的代码”,例如:

  • 函数(Functions)去替换程序中重复出现的代码块
  • (Libraries)将常用的函数打包起来,供程序员调用
  • 面向对象编程(OOP)将代码和数据捆绑在对象(Objects)中,供程序员引用
  • 对象库(Libraries of Object)
  • 框架(Frameworks,亦或平台

很多软件开发工程师从没到达过框架的层次,所以他们不懂框架是什么,也不知道它和有什么不同。

仅仅只是存放代码,函数,对象,可能还有全局变量(但很少)的容器。而框架其本身就是一个应用程序,它是一个结构,可以用来为开发者创建程序的基础部分,这样,开发者就不必一遍又一遍的,为他的每一个程序重复创建。

想象一下你是摩天写字楼的建筑商。每一栋建筑都需要一定的服务。你需要停车场,电力,给水排,电梯,空调,供暖,你还可以继续列举。再假想一下,你有一个停车场“模块”,你修改一下“停车数量”参数,然后“扑通”一声把它丢在地上,这栋写字楼的停车场就建好了。继续想象一下,你用相同的方式将剩下的电力,给水排等服务都建好了。全套繁重的写字楼设计和建筑工作就这样完成了。更进一步来讲,想象你有全套的摩天写字楼结构,你只要简单的修改一下“停车数量”,高度,宽度,建筑的层数,电力系统的安培数,电梯的个数,电梯的高度,等等。你瞬间就有了一栋高层建筑,可以开始准备招商了。

这就是框架(Framework),但要以编程的角度。

有成吨的“服务”可供你的应用程序使用的话,那是再好不过了。这些服务就是那些“模块”,当你需要它的时候就创建它,当你用完它之后就拆掉它。这当然是可行的,这也是许多程序员做事情的方式,然而,这种方式需要手动的地方非常多。

我们假定某个开发者需要一个服务,比如将所有的系统错误记录下来。这种功能最典型的实现方式是用,这意味着,你需要用这个类创建(实例化)一个对象,做完工作后,再将它卸载掉。或者,你可以让框架帮忙负责创建和卸载。你只需要调用框架的一个叫 “LogInit” 的方法,传递一个路径参数,指示你想把这个错误保存在什么地方。然后任何时候,系统发生错误,调用 “Log” 方法,传递系统的错误信息参数,系统错误就被记录下来。框架负责初始化这个 Log 类,存储路径信息,如果路径不存在则创建这个路径,当框架关闭时,卸载这个 Log 类。

再举一个稍微复杂一点的实际应用中的例子:为窗体装载控件类。我使用一个绑定窗体,我有这个窗体的类,同时也有组合框的类,文本框的类等等。组合框的类“懂得”如何处理“不在列表中”事件。如果我预先指定一个列表窗体,组合框的“不在列表中”事件会告诉用户他输入的数据不在列表中,是否想将其添加进去。如果用户说是的,类就以模式的方式打开指定的窗体。通过这个窗体,用户可以添加新的数据项进来。当用户关闭列表窗体后,组合框的类重新查询数据源,在列表窗体中新添加的数据项就可供选择了。

窗体类“懂得”如何去扫描窗体寻找放置其上的组合框控件。如果找到,框架会为每一个组合框都创建一个组合框类的实例。开发者只需要在窗体里面设置好代码,创建窗体类。窗体类会自动的去扫描和加载控件。当初始化完成,(在窗体类的 Init() 这一行之后),开发者可以为组合框指定相关的列表窗体。

所有这些功能都是框架要做的事情。对象类知道如何做事情。框架会记录对象的加载和卸载,在可能的时候自动清除掉对象。各种功能各司其职,因为框架会让这一切确保发生。

译者的话:

这篇文章主要介绍什么是框架以及与库的区别。用摩天写字楼的建设做类比也足够形象。

文中举的第二个例子,相当于我们谈论的控件子类化。将组合框的“不在列表中”事件的处理代码,从其所在窗体转移到组合框的子类中。组合框的子类由窗体的子类负责实例化。

关于该例子,后文中将会放出源码示例供大家参考。

通过子类化,你可以为 Access 的一些对象添加不存在的功能。子类化也许可以作为 VBA 的一个单独的话题拿出来讨论。

P.S.

我估计 Colby 的文章写于 2007 版 Access 出来之前,因为这之后,组合框的属性中就多了一条“列表编辑窗体”属性,开发者可以在此处直接指定一个窗体去负责处理不在列表中的事件发生时使用哪个窗体去编辑列表。

 

Access 类模块和开发框架(翻译+改编)系列之一——前言

在夜深人静的时候,我常常想,如果若干年后我不再从事 Access 开发,我所拥有的开发经验中,哪些是最值得与大家分享的?一个函数?一个算法?一个用户界面设计?一个经典项目的全部代码?都不是!

我想,没有什么比这篇文章更能代表我最想分享的内容了。它代表着编程的核心思想在Access 中的最佳实践

老实讲,这个思想不是我首创的。2008 年的某一天,忘记了是何缘故,访问到了这个网站:www.colbyconsulting.com 。里面有一个系列文章,标题就是《Access Class & Framework》。我当时还不是一个专职的 Access 开发人员,也只是偶尔用 Access 开发一些专供自己偷懒用的工具。看到这篇文章以后,我如获至宝。迅速就将所有的文档和示例文件全部下载保存下来了(事后证明这是多么明智的举动)。一两年以后,这个 Access 博客网站就变成了一个卖山地自行车的网站,Colby 放弃做 Access 咨询了?到目前为止,访问这个网站显示“因信息安全问题被屏蔽”。我后来一直在google Colby的信息,始终无法找到他。

Colby 的文章没有给你一个现成的开发框架(Framework),相反,他循循善诱,一步一步的给你娓娓道来,让你了解这个开发框架的核心思想是怎样的,如何在 Access 中去实现。我根据文章的指导,结合他给出的示例代码,创建了自己的 Access 开发框架。目前在工作中,也在使用我自己创建的开发框架。但是由于精力的缘故,一直没有对自己的开发框架进行更进一步的功能提升。例如可以将 “Access 用户界面 v1.0” 集成到开发框架中,更多的功能也能够添加到开发框架之中,好多事情都没来得及做。

现在,我准备一边编译(编辑+翻译)他的文章,一边向国内的 Access 爱好者们分享这一编程思想,同时也促成自己重温这些思想,继续提升自己的开发框架的功能。

以上。

P.S.

我将 Colby 说的 Framework 一词翻译成了“开发框架”,其实我本来是想将其翻译成“开发平台”的。后来担心与国内的 2 大 Access 论坛 / 网站上的“开发平台” 相冲突,就改成“开发框架”了。我私下认为如果你将 Framework 理解成“开发平台”也是合适的。

国内有 2 大 Access 论坛 / 网站,上面都有“Access 开发平台” 供免费 / 收费下载,都做得非常优秀。我有下载免费的版本,因为看不到核心的代码,所以不敢肯定这 2 个“开发平台” 都遵循了 Colby 文章中的思想。在仔细研究了其核心平台文件的类列表信息后,我只敢确认其中之一应该不是遵循 Colby 思想的产物,而是使用“库”(Library)来达到代码重用的目的,与“开发框架”(Framework)代码重用的方式,却差了一个级别。

Access 用户界面 v1.0(公开源代码)

Access 以简单易用而为人所知,但是用户界面设计这一块,很明显是一个短板。早期 2000 版中,将一堆命令按钮排成一列放置在窗体上,组成了简陋的“导航界面”。 2010 的版本中,加入了新的窗体类型——“导航窗体”,现代化了不少,但是用起来依然不够得心应手。

一直以来,我用的都是第三方控件,例如“ctExplorer.ocx”,界面确实非常漂亮,但部署起来好麻烦。需要将控件拷贝到每台电脑,然后注册。注册的话,又需要管理员权限,公司电脑好多用户都没有管理员权限,得向 IT 部门申请。总之,各种烦。

公司某经理换电脑了,IT 为其安装了64位操作系统,这个32位的控件,彻底不能使用了。这一回,我不得不去面对挑战。

于是在网上搜索,看有没有其他解决方法。国内有 2 个大的 Access 论坛网站,提供“ Access 开发平台”免费下载,界面看起来还不错,使用的都是 “Microsoft Web Browser” 作为导航控件,但是源代码是不公开的。作为 Access 开发人员,我不能容忍自己对自己的程序有不能掌控的地方,免费的东西有时候也往往是最贵的,于是作罢,另辟蹊径。

国外第一大 Access 论坛——www.utteraccess.com上有专门一版是讨论用户界面设计的。大多只是展示各自的用户界面,很少有源文件。唯独有 2 个可下载的示例文件,导航界面没有使用任何外部控件,全部都是 Access 的基础控件(命令按钮、子窗体等)。但若要吃透其实现思想,也不是件容易的事情,因为其中使用了类模块。

经过 几周的努力,渐渐获得了一点章法。虽然还不够完美,但是基本上能解决我的问题了。现分享给大家。

点击下载Jasoftiger’s Access UI v1.0

截图: