将PowerBuilder应用程序移植到.NET平台

Question

将PowerBuilder应用程序移植到.NET平台

c#.netmigrationpowerbuilderpowerbuilder-conversion

17

有没有人能提供将PowerBuilder 10商业应用迁移到.NET的建议？

我们公司正在考虑将遗留的PB应用程序迁移到.NET（C#），我想知道是否有任何人有经验 - 不论好坏 - 想要分享。

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

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

- Justin Ethier

给那些公司销售 PB-to-.NET 迁移服务的销售人员 - 请不要在本帖中发布广告或试图直接联系我。我对购买你们的服务不感兴趣。谢谢。 - Justin Ethier

嗨Justin - 只是好奇这里最终发生了什么？自你原始帖子以来已经过了一段时间。如果你有几分钟的时间分享，我会很感兴趣听听。我们正在查看一个PB 11.5应用程序，被要求迁移到.NET :) 谢谢！Bill - Bill Campbell

@Bill - 很不幸，事情并没有真正发生。实际上，在此期间我已经换了工作，但据我所知，早期有一个开发新系统的努力，但这将是一个全新的工程项目，不包括 PB 迁移。无论如何，祝你在努力中好运。 - Justin Ethier

9个回答

6

我认为gbjbaanb在上面给了你一个很好的答案。

还有一些值得考虑的问题：

这个PB10应用程序是一个新的、写得好的PB10应用程序，还是一个在1998年使用PB4制作的应用程序，然后逐渐转换到PB10？一个写得好的应用程序应该在业务逻辑和GUI之间有一些合理的分离，你应该能够系统地将你的代码移植到.Net。至少，这应该比如果这是一个遗留的PB应用程序要容易得多，在这种情况下，你可能会发现你的大量逻辑都被埋藏在按钮、数据窗口、菜单和其他什么东西中。虽然不是不可能，但重新工作会更加困难。
应用程序运行得如何？如果它运行良好且稳定，并且不需要很多新功能，那么也许它不需要重写。或者，就像gbjbaanb所说的那样，你可以在某些部分周围放置.Net包装器，然后暴露你需要的功能，而不需要完全重写。另一方面，如果你的应用程序难以处理，不满足业务需求，并使你的用户效率低下，那么你可能需要重写，或者进行一些严重的重构，然后进行一些增强。有一些PB的人在为第二种情况服务，过着判刑的生活，我是说，谋生。

如果软件质量极差，并对公司业务产生负面影响，我不反对重写，但即使在这种情况下，逐步调整和改进也是实现系统演进的较少风险的方式。

此外，在Terry Voth发布帖子之前不要退出这个线程。他在StackOverflow上，是PB领域的顶尖人物之一。

- Bernard Dy

4

如果代码规模较大，你最好使用.NET编写前端（或基于Web的GUI），并使用它与PB代码交互，假设你可以将其作为API公开功能，这样效果会更好。

如果你使用的是PB 9或更高版本，你可以生成COM或.NET DLL，然后通过C# GUI消耗它们。我建议你选择这种方式，而不是用新语言重写。

请记住，重写永远不是万能药，它们总是比你最初预期的更加耗时、困难和容易出错。

- gbjbaanb

3

我认为任何考虑用于大型应用程序的人都很疯狂，如果他们不非常认真地考虑使用DataWindow.NET，那么他们将会失去在DW上的投资。

- Dan Cooperstock

3

许多大公司的PHB们认为Powerbuilder只是一种玩具语言，迁移到新语言如C#是微不足道的，成本也很低。实际上，将PB应用程序迁移到任何其他语言都至少需要与使用新语言全新开发应用程序一样的成本。新应用程序通常会比原始应用程序功能更少，并导致用户不满。我见过很多尝试，但所有尝试都因困难和用户问题而失败。

如果它没有出现故障，请勿修复它。

- psant

3

你可能想花些时间研究最新发布的PowerBuilder 11.5，它增加了一些重大的.NET集成功能。为了使用新的.NET代码，迁移到PowerBuilder 11.5肯定比完全用C#重写整个应用程序更容易。

- Paul Lefebvre

3

我不知道这个(商业)产品是否好用，但是你可以看看它：PB.Net

- RealHowTo

感谢分享链接。我们团队中另一个人也刚刚发现了它。不过有点遗憾的是关于它的信息不太多，而且没有提供免费演示/试用版本，但听起来很有前途。 - Justin Ethier

3

本周我猜想是，PowerBuilder开发人员在不得不重现所有内置功能时才会意识到DataWindow的重要性。

我支持这个理论。几年前，我曾尝试将一个项目从PB8转换到Java，即使使用第一代HTML DataWindow也失败了。我的现任雇主执意转向C＃，并不使用Datawindow.NET，尽管我们当前产品中有超过2K个DWO。我不期待有一天这种认识会产生。(整个产品由几个用户应用程序、十几个服务和约70个PBD组成)

除非您的应用程序结构异常良好(可能最初是为EA Server编写的)，否则这不会是一个移植。PB和.NET环境中的工作方式有太多不同之处，因此简单的移植可能无法令人满意。我再次强调，如果您真正在使用PB事件模型，那么“移植”很可能会失败。

您需要考虑逻辑流程(交织的UI和进程)、控制流程(谁拥有进程或数据现在)、数据访问(UI、数据层、??)以及您从代码中使用的DW事件模型的部分。如果您考虑ASP.NET(正如我们所做的那样)，您的整个用户交互体验都必须改变，这将反过来影响其他方面的考虑。

与代码不直接相关的是，构建自动化将发生变化(我们使用PowerGen进行一致的PB构建；MSBuild非常不同)，您的安装和设置也会发生变化。

- DaveE

0

是的，现在可以在不重写服务组件的情况下完成。

PB 12.5 >

并将GUI和服务组件迁移和集成到C#。

迁移/集成策略可能会因您的项目范围、可扩展性、资源和时间表而有所不同。

您可以在PowerBuilder .NET中使用这些目标和项目类型。请参考此链接Sybase_PB .Net

WPF窗口应用程序 WPF窗口应用程序、WCF客户端代理或REST客户端代理
PB装配件 WCF客户端代理、REST客户端代理或PB装配件
.NET装配件 WCF客户端代理、REST客户端代理或.NET装配件
WCF服务 WCF客户端代理、REST客户端代理或WCF服务

- Mysterion

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Terry · Accepted Answer

当我看到标题时，我只是想潜水，因为我是一个著名的PB偏执者。哦，好吧。谢谢你对我的信任，伯纳德。

我的第一个建议是放弃自欺欺人的语言。如果我吃了一半“轻乳酪蛋糕”，我仍然会忘记我的腰带。迁移可能只需要10分钟。你将要做的是一次重写。时间需要作为一次重写来衡量。风险需要作为一次重写来衡量。设计工作应该被视为一次重写。

是的，我说了设计工作。 “迁移”让人想起通过某个黑匣子将代码泵送出去，并在另一端得到与原始代码镜像相同的翻译。你想复制回到1994年时所犯的同样的设计错误，这些错误你已经忍受了多年吗？即使有着优秀的代码质量，我认为PowerBuilder中的优秀设计选择可能是C#中可怕的设计选择。直接转换是否忽略了平台的力量和优势？你是否会因忽略好的C#设计而在未来15年里一直受到后果的影响？

除了那个愤怒的抱怨，由于你没有提到移动“到.NET”的动机，很难建议你采取什么措施来减轻重写的风险。如果你的管理层只是决定PowerBuilder开发人员有异味并需要被清除出办公室，那么祝你好运在重写方面。

如果你只想部署Windows表单、Web表单、程序集或.NET web服务，或者利用.NET库，那么如Paul所提到的，升级到11.0或11.5可能会使你达成目标，而且付出的努力更接近迁移。（我建议再次审查并确保你为新平台拥有良好的设计，特别是对于Web表单，但这种努力应该比重写小得多。）如果你想部署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 Forms，或者将它们放入COM callable wrapper中。或者，只需训练您的C#开发人员使用PowerBuilder。这可能只是一个谣言，但我听说新的PowerBuilder营销标语将是“如此简单，即使C#开发人员也能使用它。”;-)