POWERBUILDER开发中datawindow和直接存取的比较
POWERBUILDER开发中datawindow和直接存取的比较
用pb开发软件,免不了对数据库进行存取,datawindow是最流行的方法。FREEFORM风格基本可以代替PB中所给的其他录入控件,达到以假乱真的地步。我在实际的编码过程中发现,datawindow还是有很多缺陷的,用不好反而适得其反,事倍功半。所以有必要分析一下datawindow与直接存储的区别,在加深pb特性了解的基础上,加快开发效率,提高开发质量。
可以说datawindow和直接存取是相互矛盾的,为什么这么说呢?datawindow的长处正是直接存取的短处,反之亦然。不得不承认datawindow的优点还是很多的,比如说,填写值
的长度会在datawindow的建立过程中自动确定,accepttext函数可用来检验输入的值类型是否能被数据库接收,这两种措施,可以很好得避免手工输入过程中的人为错误。Datawindow的update函数以及bderror事件可以用来监测提交是否有错误,并及时把错误原因返回。同时datawindow有多种表现形式,图形自动生成,大大节省了开发时间。应该承认datawindow在数据控制方面已经很强了。
很遗憾,datawindow在逻辑控制反面还比较弱,笔者在开发过程中常常为此对SYBASE公司进行“诽谤”。通过实践中出现的问题,我认为datawindow的弱点在于无法对每一单元格进行编程,同时PB的bug实在不少,稳定性也差。空说无凭,举几个例子吧
例一:要求在FREEFORM风格下将某datawindow十个字段中的两个特定字段A、B设置为可编辑状态,其他为不可编辑状态。Datawindow是没有将某一具体单元格设为不可编辑状态的(也许有,我从没发现过),只能通过下面的语句Datawindow.describe(“字段名.edit.displayonly= yes”)实现。这样的确不能进行修改了,但还是能得到焦点,外观上也没变化。同时我发现Datawindow.describe(“字段名.edit.autoselect = no”)属性设置根本没作用。为了从视觉上感觉到不可编辑,还得改变一下编辑框颜色,如Datawindow.describe(“字段名.background.color = 123455755”),这样一来为了实现enable属性设置,句子就写了不少,但效果的确不怎么样。还是singleliineedit控件方便些,一句 sle_1.enabled=(true/false)就搞定了。
例二:要求在FREEFORM风格下将两个字段设为不可编辑(这两个字段各自映射一个datawindwchild),按照例一的思路只要将这两个字段都使用Datawindow.describe(“字段名.edit.displayonly= yes”)即可实现。实际并不是这样的,如果这样做pb马上发生错误(98下是这样的),从windows提示的信息来看,是内存错误,我分析原因是,pb中只有一个数据结构体用来存放临时的datawindowchild,当有两个datawindowchild需要存放时,便会发生数据溢出,进而导致严重的系统错误。
反过来,说说再直接存取的特点:可以用各种控件来对应数据库中的字段,相比之下,更有利于复杂逻辑的实现,并且容易修改,相对于数据窗口没有了那种牵一发而动全身的痛苦。但我们在编程的时候,无法忍受的另一种痛苦却会出现,为了将数据提交,必须编写恐怖的SQL语句,实际中的这种句子都很长,设计不好一个句子就得上千字节(我就有过这中痛苦的经历,MYGOOD我都不知道怎么写出来的),并且新增和修改是两个不同的语句,痛苦是双份的,对人的意志力考验也是双份的,我承认我投降了。
有了痛苦的经历,就不得不去想想办法,有什么方法可以集中datawindow和直接存取两方面的优点呢?想来想去,感觉有了一点眉目,并且是可行的。我们pb编写程序的时候不妨在界面控件和数据库中间再加上一层,这就是datastore。每个控件填写完后,自动向datastore的相关字段中填写数据,这样做等于将一个长的SQL语句化整为零了,这样一来错的概率就大大减小了(DASTOR.UPDATE()就可以完成数据的提交);同时PB中所有控件的特性我们都可以保留下来,任凭你谈出什么对话框,出发什么事件都随心所欲,引用一位朋友的话说“一切都是体力活”。
当然的,在没有复杂逻辑的情况下,datawindow还是我们的第一选择。
希望我的这一点点心得能够给刚刚走上PB开发之路的朋友们一点启发。我所说的不一定全对,但我想肯定不会全错,大家可以互相交流,取长补短,共同进步。