移植PowerBuilder应用程序到.NET [英] Porting a PowerBuilder Application to .NET

问题描述

有没有人有迁移的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＃可怕的设计选择。是否直转换忽视的力量和平台的优势是什么？你会的居住与的忽视一个不错的C＃设计，为未来15年的后果是什么？

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库，那么保罗提到，移动至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使得有可能把你的数据窗口与您联系。 （我一周的宠物的理论是，直到他们有重现所有内置于功能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应用程序是消耗品阶段过渡。如前所述，您可以产生COM对象的PB 10你有，但必须移动到11.0或11.5，生产装配。这样做的价值可能取决于你的应用程序是如何划分。如果你的业务逻辑通过蛇GUI事件和功能，而不是划分出非可视化对象（也称自定义类），这样做的价值是值得怀疑的。不过，这是一个设计的失礼的必须这样固定完全转化为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.

祝你好运发现皮带，

特里。

我看到你所提到的感动核心部件到.NET启动。正如你可能已经猜到了，我觉得分阶段的方式是一个明智的决定。现在，核心的定义可能是有争议的，但怎么样的看法相反的点。深思吗？ （显然，这是错误的一周开始节食。）根据其中，PB是正确的，现在，这将是很难划分PB和C＃以及应用程序的功能之间的应用程序（例如应收账款的PB，户口在C＃中支付）。可能工作分工GUI VS业务逻辑。如前面提到的，抽业务逻辑出的PB到可执行的C＃可以消耗已经成为可能。如何构建GUI在C＃中，从PB和业务逻辑复制的数据窗口抽出作为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.

或者，只是训练你的C＃开发人员在Pow​​erBuilder中。这可能只是一个谣言，但我听到了新的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的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！