将 PowerBuilder 应用程序移植到 .NET答案

【问题标题】：Porting a PowerBuilder Application to .NET将 PowerBuilder 应用程序移植到 .NET
【发布时间】：2009-05-05 15:18:52
【问题描述】：

有人对将 PowerBuilder 10 业务应用程序迁移到 .NET 有什么建议吗？

我的公司正在考虑将旧版 PB 应用程序迁移到 .NET (C#)，我只是想知道是否有人有任何经验（好的或坏的）想要分享。

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

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

【问题讨论】：

致其公司销售 PB 到 .NET 迁移服务的销售人员 - 请不要在此线程上发布广告或尝试直接与我联系。我对购买你们的服务不感兴趣。谢谢。
嗨贾斯汀 - 只是好奇这里会发生什么？自从您的原始帖子以来已经有一段时间了。如果你有几分钟的时间分享，我很想听听。我们正在研究一个 PB 11.5 应用程序，我们被要求迁移到 .net :) 谢谢！比尔
@Bill - 不幸的是，什么都没发生。实际上我同时换了工作，但最后我知道有一个早期的努力来开发一个新的系统，但这将是一个全新的工程工作，不包括 PB 迁移。无论如何，祝你工作顺利。

标签： c# .net migration powerbuilder powerbuilder-conversion

【解决方案1】：

当我看到标题时，我只是想潜伏，成为著名的 PB 偏执狂。那好吧。感谢您的信任投票，伯纳德。

我的第一个建议是摒弃自欺欺人的语言。如果我吃了一半“精简版”芝士蛋糕，我仍然会看不到我的腰带。迁移可能只需要 10 分钟。您将要做的是重写。时间需要作为重写来衡量。风险需要作为重写来衡量。并且设计工作应该作为重写来衡量。

是的，我说的是设计努力。 “迁移”让人联想到通过某个黑匣子抽取代码的图像，其中的翻译反映了从另一边出来的原始代码。您是否想复制 1994 年犯下的相同设计错误，而您多年来一直忍受？即使有优秀的代码，我猜 PowerBuilder 中优秀的设计选择在 C# 中可能是糟糕的设计选择。直接转换是否忽略了平台的力量和优势？在接下来的 15 年里，您会忍受忽视良好 C# 设计的后果吗？

抛开那些咆哮不谈，因为你没有提到你“迁移到 .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 事件和函数中蜿蜒而行，而不是被划分为非可视对象（也称为自定义类），那么它的价值可能是有问题的。尽管如此，这是一个设计faux pas，可能应该在完全转换为 C# 之前修复；这可以在保持 PowerBuilder 应用程序的同时完成，作为分阶段和全面转换的初步步骤。

毫无疑问，我宁愿看到您继续使用 PowerBuilder。失败了，我希望看到你成功。请记住，一旦你吃了第一口，you'll have to finish it。

祝你找到那条腰带好运，

特里。

我看到您提到将“核心组件”迁移到 .NET 以开始。正如您现在可能猜到的那样，我认为分阶段的方法是一个明智的决定。现在“核心”的定义可能是有争议的，但相反的观点又如何呢？值得深思？（显然，这周开始节食是错误的。）根据 PB 现在的位置，很难根据应用程序功能（例如，PB 中的应收账款，C# 中的应付账款）在 PB 和 C# 之间划分您的应用程序。一个可能起作用的部门是 GUI 与业务逻辑。如前所述，将业务逻辑从 PB 中抽取到 C# 可以使用的可执行文件中已经成为可能。用 C# 构建 GUI，从 PB 复制 DataWindows 并将业务逻辑作为 COM 对象或程序集抽出，怎么样？反过来，要在 PB 中使用 .NET 程序集，您要么必须升级到 11.x 并迁移到 Windows 窗体，要么将它们放在 COM callable wrapper 中。

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

【讨论】：

哇，谢谢你这么详细的回答！我们仍处于确定重写是否可行的早期阶段。我想你是对的 - 我需要从一开始就诚实地对待这一点，因为如果这是最终采用的路径，那么重写我们的应用程序将是一项巨大的努力。我们转向 .NET 的主要动机是这里的开发人员拥有比 PB 更多的 .NET 经验，尽管我同意很容易将 DataWindow 的优势视为理所当然。无论如何，再次感谢您的洞察力。
特里的杰出职位。很抱歉让你当场，但我很欣赏你所做的所有伟大的事情，并且知道你已经在 SO 上的其他 PB 问题中发布。你的宠物理论不是理论，而是现实。与我交谈的几乎每个人都对 Java 或 .Net 的 PB 打折。不能利用 Java 和 .Net 拥有的工具很糟糕，但 PB 仍然很强大，人们不知道有多少应用程序仍在其上运行。要是这么多 PB 实现没有滥用它的强大功能和灵活性就好了！
很好的回答特里。我已经投入了很多时间来跟上新技术的步伐，我的拙见是 PB 仍然在构建标准业务应用程序方面做得最好，微软正在接近 ASP.NET MVC3 并使用良好的对象存储库方法，但这不是 OP 要求的，所以我道歉。从 PB 迁移到 .NET 最终会成为重新设计，而且我见过的大多数商店都倾向于拆分更适合 Web 的部分，例如工作流功能。这并不容易，所以一定要仔细研究你想要迁移的原因。

【解决方案2】：

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

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

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

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

另外，在 Terry Voth 发帖之前不要放弃此线程。他在 StackOverflow 上，是顶级 PB 人员之一。

【讨论】：

【解决方案3】：

如果它相当大，您可能会在 .net（或基于 Web 的 GUI）中为它编写一个前端并使用它与您的 PB 代码交互，假设您可以将其作为一个API。

如果您使用的是 PB 9 或更高版本，您可以生成 COM 或 .NET dll，然后您可以通过 C# GUI 使用它们。我会推荐这个，而不是用任何新语言重写。

请记住，重写从来都不是灵丹妙药，它们最终总是比您最初预期的更加耗时、困难和错误。

【讨论】：

【解决方案4】：

您可能想花一些时间调查PowerBuilder 11.5（最近发布），它增加了一些重要的 .NET 集成。

迁移到 PowerBuilder 11.5 以使用新的 .NET 代码肯定比用 C# 完全重写整个应用程序容易得多。

【讨论】：

【解决方案5】：

我不知道它好不好，但请查看这个（商业）产品：PB.Net

【讨论】：

感谢您的链接。团队中的另一个人实际上也刚刚发现了这一点。遗憾的是没有更多关于它的信息或免费的演示/试用版，但听起来很有希望。

【解决方案6】：

本周我的宠物理论是，PowerBuilder 开发人员认为 DataWindow 是理所当然的，直到他们必须重现所有内置功能。

我支持这个理论。几年前，我在一个项目中尝试过从 PB8 到 Java 的转换，即使使用第一代 HTML DataWindow 也失败了。我现在的雇主一心想迁移到 C#，尽管我们当前的产品中有超过 2K 的 DWO，但不使用 Datawindow.NET。我并不期待实现的那一天。（整个产品由几个用户应用程序、十几个服务和大约 70 个 PBD 组成）

OP - 除非您的应用程序结构异常良好（可能最初是为 EA 服务器编写的？），否则这不会是一个端口。在 PB 和 .NET 环境中，事情的工作方式太不同了，普通端口无法令人满意地工作。这一点我怎么强调都不过分——如果你真的在使用 PB 事件模型，那么“端口”可能会失败。

您需要查看逻辑流（交织的 UI 和流程）、控制流（谁拥有流程或数据现在）、数据访问（UI、数据层，??）和您从代码中使用的 DW 事件模型的一部分。如果您正在考虑 ASP.NET（就像我们一样），您的整个用户交互体验将不得不改变，这将反馈到其他考虑因素。

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

【讨论】：

【解决方案7】：

我认为任何考虑将其用于大型应用程序的人如果不认真考虑使用 DataWindow.NET 以免失去对 DW 的投资，那将是相当疯狂的。

【讨论】：

【解决方案8】：

大公司的 PHB 认为 Powerbuilder 是一种玩具语言，迁移到像 C# 这样的新语言是微不足道的，并且可以以低成本完成。事实上，将 PB 应用程序迁移到任何其他语言的成本至少与在新语言上开发全新的应用程序一样多。与原始应用程序相比，生成的应用程序通常会失去功能，并会导致用户不满。我已经看到了许多尝试 - 由于难度和用户问题，所有尝试都失败了。

如果它没有坏，就不要修理它。

【讨论】：

【解决方案9】：

是的，现在可以在不重写服务组件期间。

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 服务

【讨论】：