问题描述

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

Does anyone have any advice for migrating a PowerBuilder 10 business application to .NET?

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

My company is considering migrating a legacy PB application to .NET (C#) and I am just wondering if anyone has any experience - good or bad - that you would like to share.

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

The application is rather large with 10 PBL libraries, some PFC as well as custom frameworks. There are a large number of DLL calls being made as well. Finally, it uses a Microsoft SQL Server database.

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

We have discussed porting the "core" application code to .NET and then porting more advanced functionality across as-needed.

推荐答案

看到标题，我就想潜伏，当个知名的PB偏执狂.那好吧.感谢您的信任投票，伯纳德.

When I saw the title, I was just going to lurk, being a renowned PB bigot. Oh well. Thanks for the vote of confidence, Bernard.

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

My first suggestion would be to ditch the language of self-deception. If I eat half of a "lite" cheesecake, I'm still going to lose sight of my belt. A migration can take as little as 10 minutes. What you'll be doing is a rewrite. The time needs to be measured as a rewrite. The risk needs to be measured as a rewrite. And the design effort should be measured as a rewrite.

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

Yes, I said design effort. "Migrate" conjures up images of pumping code through some black box with a translation mirroring the original coming out the other side. Do you want to replicate the same design mistakes that were made back in 1994 that you've been living with for years? Even with excellent quality code, I'd guess that excellent design choices in PowerBuilder may be awful design choices in C#. Does a straight conversion neglect the power and strengths of the platform? Will you be living with the consequences of neglecting a good C# design for the next 15 years?

除此之外，由于您没有提及迁移到 .NET"的动机，因此很难建议您可能需要哪些选项来降低重写风险.如果您的管理层只是决定 PowerBuilder 开发人员闻起来很糟糕，需要从办公室中删除，那么祝您重写顺利.

That rant aside, since you don't mention your motivation for moving "to .NET," it's hard to suggest what options you might have to mitigate the risk of a rewrite. If your management has simply decided that PowerBuilder developers smell bad and need to be expunged from the office, then good luck on the rewrite.

如果您只是想部署 Windows 窗体、Web 窗体、程序集或 .NET Web 服务，或利用 .NET 库，那么正如 Paul 所提到的，迁移到 11.0 或 11.5 可以让您实现目标，并且努力接近迁移.(我建议再次审查并确保您已经为新平台设计了一个好的设计，尤其是 Web 窗体，但这种工作应该比重写要小得多.)如果您想部署 WPF 应用程序，我知道一年的等待时间很长，但研究 PowerBuilder 12 可能是值得的.如果正确使用，WPF 功能可能会将 PowerBuilder 置于独特而强大的位置.

If you simply want to deploy Windows Forms, Web Forms, Assemblies or .NET web services, or to leverage the .NET libraries, then as Paul mentioned, moving to 11.0 or 11.5 could get you there, with an effort closer to a migration. (I'd suggest again reviewing and making sure you've got a good design for the new platform, particularly with Web Forms, but that effort should be significantly smaller than a rewrite.) If you want to deploy a WPF application, I know a year is quite a while to wait, but looking into PowerBuilder 12 might be worth the effort. Pulled off correctly, the WPF capability may put PowerBuilder into a unique and powerful position.

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

If a rewrite is guaranteed to be in your future (showers seem cheaper), you might want to phase the conversion. DataWindow.NET makes it possible to to take your DataWindows with you. (My pet theory of the week is that PowerBuilder developers take the DataWindow for granted until they have to reproduce all the functionality that comes built in.) Being able to drop in pre-existing, pre-tested, multi-row, scrollable, minimal resource consuming, printable, data-bound dynamic UI, generating minimal SQL with built-in logical record locking and database error conversion to events, into a new application is a big leg up.

您还可以通过将 PowerBuilder 代码转换为可由 .NET 应用程序使用的东西来分阶段进行转换.如前所述，您可以使用现有的 PB 10 生成 COM 对象，但必须移至 11.0 或 11.5 才能生成程序集.这个值可能取决于您的应用程序的分区程度.如果您的业务逻辑在 GUI 事件和函数中蜿蜒而行，而不是被划分为非可视对象(也称为自定义类)，那么它的价值可能值得怀疑.尽管如此，这是一个设计faux pas，可能应该在完全转换为 C# 之前修复；这可以在保持 PowerBuilder 应用程序的同时完成，作为分阶段和全面转换的初步步骤.

You can also phase the transition by converting your PowerBuilder code to something that is consumable by a .NET application. As mentioned, you can produce COM objects with the PB 10 you've got, but will have to move to 11.0 or 11.5 to produce assemblies. The value of this may depend on how well partitioned your application is. If your business logic snakes through GUI events and functions instead of being partitioned out to non-visual objects (aka custom classes), the value of this may be questionable. Still, this is a design faux pas that should probably be fixed before a full conversion to C#; this is something that can be done while still maintaining the PowerBuilder application as a preliminary step to a phased and then a full conversion.

毫无疑问，我宁愿看到您继续使用 PowerBuilder.失败了，我希望看到你成功.请记住，一旦你吃了第一口，你必须吃完.

No doubt I'd rather see you stay with PowerBuilder. Failing that, I'd like to see you succeed. Just remember, once you take that first bite, you'll have to finish it.

祝你找到那条腰带好运，

Good luck finding that belt,

特里.

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

I see you've mentioned moving "core components" to .NET to start. As you might guess by now, I think a staged approach is a wise decision. Now the definition of "core" may be debatable, but how about a contrary point of view. Food for thought? (Obviously, this was the wrong week to start a diet.) Based on where PB is right now, it would be hard to divide your application between PB and C# along application functionality (e.g. Accounts Receivable in PB, Accounts Payable in C#). A division that may work is GUI vs business logic. As mentioned before, pumping business logic out of PB into executables C# can consume is already possible. How about building the GUI in C#, with the DataWindows copied from PB and the business logic pumped out as COM objects or assemblies? Going the other way, to consume .NET assemblies in PB, you'll either have to move up to 11.x and migrate to Windows Forms, or put them in a COM callable wrapper.

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

Or, just train your C# developers in PowerBuilder. This just may be a rumour, but I hear the new PowerBuilder marketing tag line will be "So simple, even a C# developer can use it." ;-)

这篇关于将 PowerBuilder 应用程序移植到 .NET的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！