PB程序员必读

PB的正面评价----我的PB观之一
  PB是一个最快速的客户机/服务器开发工具,这一点已被无数次实践证实。
  PB的快速来自以下几个方面:
  一:数据窗口:
  PowerBuilder仍然具有最强大的报表功能,只有它具有可以直接在应用程序中使用的报表生成器。PowerBuild支持Crosstab、图形报表,nested报表以及其他一些吸引人的特性。
  数据窗口将报表打、录入修改功能集成在一起,画好一个数据窗口同时就完成了数据的增、删、查、改、打功能,其效率比DELPHI等提高了几倍以上。
  而且由于数据窗口将数据处理生成SQL打包,PB程序员不必象一些DELPHI程序员一样进行拼将SQL的处理(DELPHI的DBEDIT,DBGRID普遍不受欢迎)。
  数据窗口有PB的属性表支持,在利用建模工具生成扩展属性,画数据窗口将以10秒单位计算工作量,而且利用它可以直接在应用生成报表。
  二:代码继承(PFC或自定义基类库):
  PB对面向对象的继承、重载支持得很早,比VB在这方面强大了很多。
  利用PB的代词(this、parent等)及数据窗口对象的内在属性,PB程序员可以很容易建立通用祖先模块。
  而PFC提供了大量的附加功能,如果你怕PFC太过庞大,你也可以自己写一个基类库,现在我们公司就是这么做的。
  三:建模工具:
  PB有一个同胞兄弟POWERDESIGNER,如果大家还没用过的话,那么你将浪费很多的时间在一些重复劳动上。
  PD可以将数据库的属性生成到PB的扩展属性中,并可以直接生成应用。
  如果是一些基本的数据操作模块,那么,在PDM设计完成后,不用进PB,在几分钟内,应用系统就已经完成了。
  四:其他:
  如SQL语句的内部嵌入等
  小结:
  所以,一个熟练PB程序员的工作效率等于三个DELPHI程序员两个VB程序员,
  在开发数据库应用时,PB是首要选择。
  从其最早版本开始,Powerbuider就把应用程序开发重心放在数据窗口上。
  而DW的最大作用是解决了客户界面与后台数据库之间的可视连接。
  由于Pb对数据窗口的依赖性,以及数据窗口本身的自顶向下继承模型决定了PB不适于组件重用的开发环境。
  所以正如<我的PB观二>所述,我对PB的CTS开发不感兴趣。
  但从另一方面来看,由于DW控件与DW对象之间的独立与内在联系规律,我们可以轻而易举地建立功能重用。
  其他任何一种开发工具不可能生成如PB一般丰富的通用增、 删、查、改、打模块。
  这更确立了PB在开发客户机/服务器应用方面的优势。
  
PB的正面评价----我的PB观之二
  一:PB的开发速度是所有开发工具中最快速的
  这在我的PB观之一中已有说明,不再重复。
  
  二:PB的执行效率是所有开发工具中最差的。
  在性能方面PowerBuilder与VB、DELPHI不在同一档次上。生成DLL慢先不说,它在客户机/服务器方式下执行还很慢,
  在三层开发时更慢,而在Web应用中慢得令人认为它停止运行了。
  ISAPI连接不工作,使性能问题更加糟糕。7.0版与6.0版相比没有明显的性能改善。
  这我想这可能是和公司的技术积累有关。VB是MS的产品,自不必说,而DELPHI是Borland公司的孩子(想想我们十年前用的TC2.0吧),
  PB当年推出时POWERSOFT靠着数据窗口一举成名,当时,PB甚至还不能生成DLL。而SYBASE收购POWERSOFT后,也没有在这方面进行发展,到现在我们还要牢记发布时要带着PBVMX.dll等。
  
  三:PB的三层及WEB开发
  PB提供的WEB及三层开发除JUGUAR外我都曾用它开发过项目,下面是我的一些体会:
  Powerbuilder的物理分布是基于数据窗口的。数据窗口运行于每个用户的工作站上,它是综合了商务服务和用户服务的物理组件,
  也是每个终端用户持续使用数据库资源的接口元件。在分布式环境下,诸如数据库连接之类的资源可以通过缓冲而得到更好的利用。
  但Powerbuilder并没有提供这种缓冲机制。因而随着用户数量的增加,系统的效率会越来越差。
  PB的WEB开发是一个PB提供的执行模块把Web服务器生成的ISAPI、NSAPI及CGI请求映像为PowerBuilder远端过程调用,
  这些额外开销影响了服务器的性能。PowerBuilder应用程序的配置包括PowerBuilder小模块,即一个启动应用的小执行体,
  一个真正应用程序代码的DLL,一个支持PowerBuilder Web库的DLL以及将它们组合在一起的一个pbweb.ini文件。
  PB提供的三层开发利用插入件技术可以很方便地移植到WEB上,而且可以保留几乎所的PB功能。
  三层开发加上CGI技术可以很方便生成纯WEB应用(主要是指DW的重用)。以上两种方案是最简单的PBWEB方案。
  在利用DW DTC生成WEB DATAWINDOWS时,由于使用技术问题,PB实际上只能完成数据窗口的制作,其他工作是POWERSITE的事了
  (虽然PB8将他们集成在一起)。
  在利用JUGUAR时,无法生成中文,到PB8时,这问题也没有得到改善(不知是不是我的错,反在在装好PB8时,看着JUGUAR菜单上的方块,
  我想可能是失败了)。
  用PowerBuilder进行Web站点开发过于繁琐。只有Pb不允许在浏览器中进行调试应用程序,相反每个功能块都必须作为单独应用程序进行测试,
  然后期望它能正确运行在Web浏览器中。配置后应用程序的性能是不可知的。
  另外:
  PowerBuilder对流程的控制比Visual Basic还要差,调试器在多组件的环境中毫无用处。PowerBuilder中的调试方法一般是先在单用户
  非分布的环境中测试组件(任何语言都可做到),然后期望它可以在分布式多组件的环境下正常工作(不是好的做法)。
  PowerBuilder差劲的性能决定其在开发服务器应用时无大作为。在一个快速的客户端,可以花费一定的处理器周期运行PowerBuilder脚本,
  但在一个需要为几百个用户并发服务的服务器上,不可能使用PowerBuilder。
  PB Web方案的健壮性是可怕的,使用ISAPI时整个Web服务器经常崩溃。甚至在我们使用原来的CGI时,偶尔也会见到PowerBuilder CGI
  模块出现保护错。
  所以在一些关键业务WEB应用在用PB开发完成以后,我又用DELPHI重新写了一次。
  四:PB的组件开发
  PowerBuilder组件只对于其他PowerBuilder应用程序有用,在使用多种语言环境中,使用这些组件所受的限制将使其他一些优点变的没有意义。
  组件不能静态键入,也不能被调试,用户只能在单独安装了PowerBuilder的机器上使用这些组件。
  所以我对PB的CTS开发一直不感兴趣。
  
  五:PB与其他技术的集成
  PB与其他技术的集成一直不好。
  先说API调用,在PB中没有已定义的WINDOWSAPI结构、枚举,不能定义嵌套结构,不能使用回调函数。
  这在使用一些WINDOWSAPI时问题还不是很大,但在进行一些与硬件产品有关的开发时,那些厂商提供的SDK五花八门,PB就无能为力了。
  再说OLE调用,在PB中没有对OLE语法的检查及提示,一切只是摸石头过河,还经常出错。
  六:PB的技术前景
  PB的发展到了一个关键时候,在现在三层技术及WEB开发渐成气候,面向对象设计成为潮流的时候,我们发现,SYBASE做得不能让我们满意。
  如第三点所说的三层模式下的些缺点,PB不是一个好的三层开发工具。
  在建模理论方面以前PD6对PB快速开发支持得很好,但从PD7以后,PD不能直接生成PB的数据窗口及应用,
  只能从所谓面向对象设计原理出发生成USEROBJECT,功能弱地根本不能升级。
  而面向对象设计中PB的数据窗口定位
  
PB程序员的前途----我的PB观之三
  一:PB程序员仍有价值
  如我的PB观之一、二所说,PB真正的价值在快速开发客户机/服务器应用,而这些就已经能应付目前国内70%的项目。
  所以我相信,只要能熟练掌握,并能发挥出PB的快速优势,那么,任何一个公司都会需要这样的程序员。
  (如有想来福州工作的PB程序员可以和我联系weilong_chen@21cn.com)
  比如说我们公司,所做的项目还是以定制软件为主,在这种情况下,PB是一个极具竞争力的工具,从公司角度考虑,
  能快速完成项目是根本目的。项目开发周期承诺甚至影响到项目的获得。
  
  二:PB程序员应注意的问题
  PB的学习应该是一个扎实的过程,建议读一本全面介绍PB的书,这样你会更理解PB能做什么,又该如何实现。这是做一个PB
  程序员必由之路。因此三天可以使用PB,但要真正精通一定是一个漫长的过程。
  作为一名公司负责人,我可以更关注项目的执行,但是作为一名程序员,应更关注知识的全面化。所以在了解PB的同时,
  PB程序员还应注意以下几方面能力的培养:
  1:数据库特别是SQL语句的理解。这是所有数据库开发人员应具备的基本素质。如果你只是利用PB进行数据操作而不
  去学习SQL语句,那么有一天公司让你进行一个ASP开发或是转向其他工具,你会发现你突然变得如此困难。
  2:建模工具的使用。建模工具对规范化软件设计有着非常重要的意义。推荐使用POWERDESIGNER,因为PD与PB在APPMODEL结合
  地不错(指PD6),而这也是所有数据库开发的必由之路。
  
  三:PB程序员应补充的知识
  我发现一些PB程序员的知识面过于狭窄,离开C/S模式就无法工作,这是非常危险的。即使是PB自己也在不断进步,哪一天结束学习,就意味着结束了你的程序员生涯(虽然这未必是坏事)。
  三层开发:虽然如第二篇所说,PB的三层开发存在许多问题,但在低负载情况下还是可以支撑的,而且对PB程序员来说
  实现PB的三层开发一点也不困难
  (不一定要看一些书上说的方法,可以考虑制作一个通用库,那么开发三层和两层在开发方法上基本没有区别,这些将在后续文章中进行介绍)。
  WEB开发:PB的WEB开发比较可行的方法我个人认为是插入件技术+三层(胖客户机模式)和WEBPB(瘦客户机模式),开发
  模式和三层结构差不多。这点高辉推荐使用SYBASE的EAS方案,我个人认为从技术上SYBASE准备不够(BUG太多),而且作为PB的C/S程序员
  移植成本太大(那些除了DW基本上都与原来的PB没有太大的联系)。
  花同样的时间,你完全可以了解MS的ASP、.NET。(这也是我最近转到CSDN的原因)
  最后愿大家都有好心情。(
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值