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开发之路的朋友们一点启发。我所说的不一定全对，但我想肯定不会全错，大家可以互相交流，取长补短，共同进步。