窗体设计是很重要的一个环节，其原因在于窗体是人机交互的界面，由这个交互来体现管理的过程。但窗体设计的自由度较之数据表的设计大很多，几乎没有什么一定之规，所以便会千人千面。即使如此，可能也需要考虑一些因素。就我的看法来说，至少要考虑这样几个方面的问题：其一是窗体是否与业务过程一致；其二是窗体呈现的内容是否易于理解；其三是窗体的操作是否便捷；其四是窗体是否可设计的相对一致；其五是窗体是否美观。

　　就此示例，重点说一下监测主窗体的设计。该窗体左侧为一个TreeView控件，准备按照监测类型、年度、监测任务三层节点来呈现监测任务；右上部由若干控件组成监测任务的编辑区域；右下部由一个子窗体加上控件组构成监测指标的编辑区。这个窗体中与监测任务的业务处理相吻合，也就是说每次完成监测任务后，都集中在这个窗体中处理就可以了。有一个问题需要注意，也就是监测点的数据处理并没有在这个窗体中进行。这是因为虽然监测任务的数据依赖监测点的数据，但它们是两个业务处理过程。监测点一般是按照年度一次性确定的，数据变化不大，因此不必要将其放到监测任务的窗体中来处理。强调这个问题的原因，是源于经常看到初学者喜欢不区分过程，不区分处理环节，把一大坨东西全部整在一个窗体上。这样做不仅让人眼花缭乱，也不仅违背了业务管理的客观规律，而且也增加了代码的复杂性。

　　另外再说明一下窗体相对一致性设计的问题。在本系统中，我对大多数数据表在窗体上的操作，都是采用一个子窗体加上主窗体上的一组未绑定控件来处理。其中要点是子窗体的数据源类型为快照，主窗体上的未绑定控件与子窗体的控件在数量和名称上一致（可用复制粘贴方法进行）。这样做的好处，你可以在下一课中看到，就是可以编写一些通用的函数和子程序对这些窗体的增删改做一致性的处理。

　　还是回到前面的说法上来，窗体设计的自由度很大，很难评判优劣好赖（除非太操蛋的）。所以本例的处理并非一个标准的处理方法。


上一课　下一课

示例：点击下载此附件

 

视图：