将PowerBuilder应用程序移植到.NET

Question

有没有人有任何建议将PowerBuilder 10业务应用程序迁移到.NET？

我的公司正在考虑将传统的PB应用程序迁移到.NET(C#),我只是想知道是否有人有任何经验 - 好的或坏的 - 你想分享.

该应用程序相当大,包含10个PBL库,一些PFC以及自定义框架.还有大量的DLL调用.最后,它使用Microsoft SQL Server数据库.

我们已经讨论过将"核心"应用程序代码移植到.NET,然后根据需要移植更高级的功能.

Answer 1

当我看到这个头衔时,我只是潜伏着,成为着名的PB bigot.那好吧.感谢Bernard的信任投票.

我的第一个建议是放弃自欺欺人的语言.如果我吃一半"精简"芝士蛋糕,我仍然会看不到我的皮带.迁移只需10分钟.你要做的是改写.的时间需要作为重写要被测量.该风险需要作为重写来衡量.与设计工作应作为一个重写进行测量.

是的,我说设计工作."迁移"通过一些黑盒子让人联想到泵送代码的图像,翻译镜像原来的另一面.你想复制1994年你曾经生活多年的同样的设计错误吗？即使有优质的代码,我猜想PowerBuilder中出色的设计选择可能是C#中糟糕的设计选择.直接转换会忽略平台的强大功能吗？你将与住忽略良好的C#设计,为未来15年的后果是什么？

除此之外,由于你没有提到你转向".NET"的动机,因此很难说明你可能有哪些选择来降低重写的风险.如果你的管理层只是认为PowerBuilder开发人员闻起来很糟糕并且需要从办公室中删除,那么祝你好运.

如果您只是想部署Windows窗体,Web窗体,程序集或.NET Web服务,或者利用.NET库,那么正如Paul所说,迁移到11.0或11.5可以帮助您实现迁移.(我建议再次检查并确保你已经为新平台设计了一个好的设计,特别是使用Web Forms,但这项工作应该比重写要小得多.)如果你想部署一个WPF应用程序,我知道一年是等待很长一段时间,但是看看PowerBuilder 12可能是值得的.正确拉出,WPF功能可能使PowerBuilder成为一个独特而强大的位置.

如果保证将来重写(淋浴似乎更便宜),您可能希望逐步进行转换.DataWindow.NET使您可以随身携带DataWindows.(我本周的宠物理论是,PowerBuilder开发人员认为DataWindow是理所当然的,直到他们必须重现内置的所有功能.)能够放入预先存在的,预先测试的,多行的,可滚动的,最小的资源消耗,可打印,数据绑定的动态UI,生成最小的SQL,内置逻辑记录锁定和数据库错误转换为事件,进入一个新的应用程序是一个很大的问题.

您还可以通过将PowerBuilder代码转换为.NET应用程序可以使用的代码来分阶段转换.如上所述,您可以使用您已获得的PB 10生成COM对象,但必须移至11.0或11.5才能生成程序集.这个值可能取决于您的应用程序的分区程度.如果您的业务逻辑通过GUI事件和函数进行窃取而不是被分区到非可视对象(也称为自定义类),那么这个值可能会有问题.不过,这是一个设计失礼应可能是一个完全转化为C#前固定; 这是可以完成的,同时仍然将PowerBuilder应用程序作为分阶段然后完全转换的初步步骤.

毫无疑问,我宁愿看到你留在PowerBuilder.如果做不到这一点,我希望看到你成功.请记住,一旦你吃了第一口,你就必须完成它.

祝好运找到腰带,

特里.

我看到你提到将"核心组件"移动到.NET开始.正如你现在可能猜到的那样,我认为分阶段的方法是一个明智的决定.现在,"核心"的定义可能是有争议的,但如何相反的观点.深思熟虑？(显然,这是开始节食的错误一周.)根据PB现在的位置,很难将应用程序在PB和C#之间沿应用程序功能划分(例如PB中的应收帐款,C#中的应付帐款).可能有效的部门是GUI与业务逻辑.如前所述,将业务逻辑从PB中抽入C#可以消耗的可执行文件已经成为可能.如何在C#中构建GUI,从PB复制DataWindows并将业务逻辑作为COM对象或程序集抽出？换句话说,要在PB中使用.NET程序集,您要么必须升级到11.x并迁移到Windows窗体,要么将它们放在COM可调用包装器中.

或者,只需在PowerBuilder中培训您的C#开发人员.这可能只是一个谣言,但我听说新的PowerBuilder营销标签将是"如此简单,即使是C#开发人员也可以使用它".;-)

Answer 2

我想gbjbaanb给了你一个很好的答案.

其他一些值得考虑的问题:

• 这款PB10应用程序是一款全新的,写得很好的PB10应用程序,还是1998年在PB4上制造的应用程序,多年来逐渐转换为PB10？一个编写良好的应用程序应该在业务逻辑和GUI之间进行一些适当的隔离,并且您应该能够系统地将代码移植到.Net.至少,它应该比这是一个传统的PB应用程序容易得多,在这种情况下,很可能你有大量的逻辑埋在按钮,数据窗口,菜单,谁知道还有什么.并非不可能,但更难以返工.
• 该应用程序的运行情况如何？如果它可以稳定,并且不需要很多新功能,那么它可能不需要重写.或者,正如gbjbaanb所说,你可以将.Net包装器放在一些部件上,然后在没有完全重写的情况下公开你需要的功能.另一方面,如果您的应用程序是恶劣的,令人讨厌的,不是真正令人满意的业务需求,并且使您的用户效率低下,那么您可能会有重写案例,或者可能是一些严重的重构,然后是一些增强功能.有PB人服刑,呃,我的意思是,用第二种情景谋生.

如果软件非常差并且对公司的业务产生负面影响,我不反对重写,但即使这样,逐步调整和改进也是实现系统发展的风险较小的方法.

此外,在Terry Voth发布之后,不要保释这个帖子.他在StackOverflow上,是最顶尖的PB之一.