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的原因）
最后愿大家都有好心情。(
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的原因）
最后愿大家都有好心情。(
扫一扫
2588
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
