问将PowerBuilder应用程序移植到.NET

EN

当我看到标题的时候，我正准备潜伏着，成为一个著名的PB狂热分子。哦，好吧。谢谢你的信任票，伯纳德。

我的第一个建议是抛弃自欺欺人的语言。如果我吃了半个“清淡”的芝士蛋糕，我还是会看不到我的腰带。一次迁移可能只需要10分钟。你要做的是重写。time需要作为重写进行测量。risk需要作为重写进行测量。而设计工作应该作为重写来衡量。

是的，我说的是设计努力。“迁移”会让人联想到通过某个黑盒抽出代码的图像，其中的翻译反映了另一边出来的原始代码。你想重复1994年的设计错误吗?你已经忍受了很多年了？即使有高质量的代码，我也猜测在PowerBuilder中优秀的设计选择在C#中可能是糟糕的设计选择。直接转换会忽略平台的能力和优势吗？在接下来的15年里，你会因为忽视一个好的C#设计而生活在后果中吗？

抛开这句大喊大叫不谈，因为您没有提到您“转向.NET”的动机，所以很难建议您可能有哪些选项来减轻重写的风险。如果您的管理层只是简单地决定PowerBuilder开发人员很糟糕，需要将其从办公室中剔除，那么祝您重写好运。

如果您只是想部署Windows Forms、Web Forms、Assemblies或.NET web服务，或者利用.NET库，那么就像Paul提到的那样，迁移到11.0或11.5可能会让您更接近迁移。(我建议再次审查并确保您已经为新平台设计了一个好的设计，特别是Web表单，但这项工作应该比重写要小得多。)如果你想部署一个WPF应用程序，我知道等待一年是相当长的一段时间，但是研究一下PowerBuilder 12可能是值得的。如果处理得当，WPF功能可能会使PowerBuilder处于一个独特而强大的位置。

如果将来肯定会进行重写(showers似乎更便宜)，那么您可能需要分阶段进行转换。DataWindow.NET使随身携带DataWindows成为可能。(我最喜欢的理论是，PowerBuilder开发人员认为DataWindow是理所当然的，直到他们不得不重现内置的所有功能。)能够将预先存在的，预先测试的，多行的，可滚动的，最小的资源消耗，可打印的，数据绑定的动态UI，生成具有内置逻辑记录锁定和数据库错误转换到事件的最小SQL，到一个新的应用程序中是一个很大的优势。

您还可以通过将PowerBuilder代码转换为.NET应用程序可以使用的代码来对转换进行阶段化。如前所述，您可以使用已有的PB 10生成COM对象，但必须迁移到11.0或11.5版本才能生成程序集。它的值可能取决于应用程序的分区情况。如果您的业务逻辑遍历GUI事件和函数，而不是划分为非可视对象(也称为自定义类)，那么这一点的价值可能会受到质疑。尽管如此，这仍然是一个设计上的失误，应该在完全转换到C#之前解决；这是可以做到的，同时仍然将PowerBuilder应用程序作为分阶段转换的初步步骤，然后再进行完全转换。

毫无疑问我更愿意看到你和PowerBuilder在一起。如果做不到这一点，我希望看到你成功。记住，一旦你咬了第一口，you'll have to finish it。

祝你好运找到那条腰带

特里。

我注意到你已经提到将“核心组件”转移到.NET开始。正如您现在可能猜到的那样，我认为分阶段的方法是一个明智的决定。现在“核心”的定义可能会有争议，但是相反的观点又如何呢？发人深省？(显然，这周不是开始节食的时候。)根据PB现在所处的位置，很难根据应用程序功能(例如PB中的应收账款、C#中的应付账款)在PB和C#之间划分您的应用程序。一个可能可行的划分是GUI与业务逻辑。正如前面提到的，将业务逻辑从PB中抽取到C#可以使用的可执行文件中已经是可能的。用从PB复制的DataWindows和作为COM对象或程序集输出的业务逻辑在C#中构建图形用户界面怎么样？另一方面，要在PB中使用.NET程序集，您必须升级到11.x并迁移到Windows Forms，或者将它们放在COM callable wrapper中。

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

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

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

• 这个PB10应用程序是一个新的、编写良好的PB10应用程序，还是在1998年用PB4开发的，然后随着时间的推移逐渐转换为PB10的应用程序？一个编写良好的应用程序应该在业务逻辑和图形用户界面之间有适当的分离，并且您应该能够系统地将代码移植到.Net。至少，它应该比如果这是一个遗留的PB应用程序容易得多，在这种情况下，你可能会有大量的逻辑埋藏在按钮，数据窗口，菜单中，谁知道还有什么。不是不可能，但更难返工。
• 应用程序运行得如何？如果它是好的和稳定的，并且不需要太多的新特性，那么它可能不需要重写。或者，正如gbjbaanb所说，您可以在某些部分周围放置.Net包装器，然后在不完全重写的情况下公开所需的功能。另一方面，如果你的应用程序不好用，令人讨厌，不能真正满足业务需求，并且让你的用户效率低下，那么你可能有理由重写，或者进行一些认真的重构，然后再进行一些增强。有PB的人在服刑，呃，我的意思是，用第二种情况谋生。

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

另外，在Terry Voth发布帖子之前不要放弃这个帖子。他在StackOverflow上，是顶尖的PB人员之一。

如果它相当大，你可以在.net (或基于web的图形用户界面)中为它编写一个前端，并使用它与你的PB代码交互，假设你可以将它的功能公开为一个应用程序接口，那么你可能会得到更好的结果。

如果您使用的是PB 9或更高版本，则可以生成COM或.NET dlls，然后可以通过C#图形用户界面使用它们。我建议你这样做，而不是用任何一种新的语言重写。

请记住，重写从来不是灵丹妙药，它们最终总是比你最初预期的更耗时、更困难、更有buggy。