基于VB6开发的业务建模平台重构(不断更新中)

前言：作为一种‘古老’的IDE及开发语言，现在谈及VB6有一种翻古书的感觉，在2004年全年的开发中我却是使用得最多。平心而论，从大学开始我一直对VB无甚好感（呵呵，高中时其实也是从BASIC起步的），其起源在于BASIC的编码方式，很容易让生性懒散的我把代码写得非常难看。作为一个有不算太短编码历程（10年左右吧）的人来说，现在我只能算是一个流氓程序员，经常写着快而脏的代码，这段时间呢，忽然觉得不能老是以项目太多老板逼得太紧来做借口，回避对结构的合理分析，就算懒也要有点技术含量吧，呵呵。

• 项目介绍：

我非常想完整详细地描述整个项目，这样对我往后的分析也方便些，但毕竟我拿着老板的薪水，所以部分细节还是属于公司的，因此在网上我会适当地作些处理。如果有那位大侠看到这篇小文，细节之处还请见谅。
该项目最终的形态是一个针对各种单证的建模工具，应用的范围是非常广泛的，使用该工具对各种现实中的单证进行电子化建模后，就可以成为OA或ERP中的业务处理对象，其实这种单证＋工作流的思路很多年来就一直是业务处理的解决方案，市场上也有了很多的产品，从MS的INFOPATH到我们公司开发的自主产品纷纷繁繁，暂且撇开其市场价值与市场前景，就事论事先吧。
电子单证系统从构建方式上分为两种：基于表格（base grid）和基于面板（base panel）两种。简言之，基于表格的操作方式就是EXCEL的方式，整个电子表单是一个二维规整的单元格集合；基于面板的操作方式对于经常使用IDE的程序员应该很容易接受，就是类似VB的FORM DESINER或者DELPHI上的panel。这两种方式各有利弊，在选择时我也费了不少脑筋，从程序员角度，用得爽看起来专业的话肯定是使用面板的方式，对于客户也是一样的，选一个文本框之后，爱放哪儿就放哪儿，但这样做呢编码的工作量大，也有不少技术细节，例如说定位就不是很容易解决，而基于表格呢，看起来确实是不太爽，但他的规整就是一个最大的好处，而且可以直接把EXCEL嵌进来，其实也可以用其它的第三发控件例如F1BOOK之类的，都很多很成熟了。很多时候，也是一种平衡，资源（包括技术人力时间）与功能、市场的平衡，所以我还是旋转了基于表格的思路。

• 针对系统的核心部分第一次重构
• • 核心部分描述。一般的电子单证都是由若干个域构成，既然我选择了基于表格的实现方法，那么就可以对单元格进行定义，使之成为业务相关的域。这样做也有个好处，通过对物理单元格的组合拆分编辑，可以得到不同的格式，操作上类似EXCEL。整个系统最重要的工作也就包括域的定义和域的组织。根据域的显示形式可以分为单一的主域和二维的域集合，例如说一张销售单，上面的客户姓名，地址等等就是主域（以下称主表域），而商品列表就是一个域集合（以下称子表域）。域的组织我使用树来做导航。
    这里我针对销售单上‘客户姓名’这个业务对象来描述如何定义主表域，工作人员一看到销售单上的客户，当然就知道在这栏应该填上某人的姓名，电子单证定义的目的就是为了让计算机也象人一样知道这个地方该填什么信息。因此定义的时候我们所有工作的目的就是把‘客户姓名’这个对象映射到数据库中的‘custmername’字段，其中包括该字段的类型，长度等等信息，另外还要让计算机从数据库中提取数据回写‘客户姓名’时，该写到哪儿，怎么写，于是我们还得提供一个格式描述的XML文件。从这个角度而已这也是一种MVC的思路，单证数据和单证格式是分离的，而定义的过程也可以看成是MODEL和VIEW的定义过程。至于CONTROL，则是表单解释引擎的工作，属于整个系统的服务端，这里就不深入描述了。
    销售单上的商品列表是一个典型的二维集，因为所购买的商品一般是多个的，而且每个商品对象的结构是相同的（包括价格，数量，小计等等），在处理的粒度上应该把整个列表看成一个业务对象。