有没有人对将PowerBuilder 10业务应用程序迁移到.NET有任何建议？
我的公司正在考虑将传统的PB应用程序迁移到.NET（C＃），我只是想知道是否有人有任何经验 - 好的或坏的 - 你想分享。
应用程序非常庞大，包含10个PBL库，一些PFC以及自定义框架。还有大量的DLL调用。最后，它使用Microsoft SQL Server数据库。
我们已经讨论过将“核心”应用程序代码移植到.NET，然后根据需要移植更多高级功能。
答案 0 :(得分：23)
当我看到这个头衔时，我只是潜伏着，成为着名的PB bigot。那好吧。感谢Bernard的信任投票。
我的第一个建议是放弃自欺欺人的语言。如果我吃一半“精简”芝士蛋糕，我仍然会看不到我的皮带。迁移只需10分钟。你将要做的是重写。 时间需要作为重写进行衡量。 风险需要作为重写进行衡量。 设计工作应该作为重写来衡量。
是的，我说过设计工作。 “迁移”通过一些黑盒子让人联想到泵送代码的图像，翻译镜像原来的另一面。你想复制1994年你曾经与生活多年的设计错误吗？即使有优质的代码，我猜想PowerBuilder中出色的设计选择可能是C＃中糟糕的设计选择。直接转换会忽略平台的强大功能吗？你是否与一起生活在未来15年忽视一个好的C＃设计的后果？
除了咆哮之外，由于你没有提到你转向“.NET”的动机，因此很难说明你可能有哪些选择来降低重写的风险。如果您的管理层只是认为PowerBuilder开发人员闻起来很糟糕并且需要从办公室中删除，那么祝您好运。
如果您只是想部署Windows窗体，Web窗体，程序集或.NET Web服务，或者利用.NET库，那么正如Paul所说，移动到11.0或11.5可以帮助您实现目标，迁移。 （我建议再次检查并确保你已经为新平台设计了一个好的设计，特别是使用Web Forms，但是这个工作应该比重写要小得多。）如果你想部署一个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＃开发人员也可以使用它”。 ; - ）
答案 1 :(得分：6)
我认为gbjbaanb给了你一个很好的答案。
其他一些值得考虑的问题：
如果软件非常差并且对公司的业务产生负面影响，我不反对重写，但即使这样，逐步调整和改进也是实现系统发展的风险较小的方法。
另外，在Terry Voth发帖之前，不要保释这个帖子。他在StackOverflow上，是最顶尖的PB之一。
答案 2 :(得分：4)
如果它相当大，你可能会有更好的结果在.net（或基于网络的GUI）中为它编写前端并使用它来与你的PB代码交互，假设你可以将它作为一个API。
如果您使用的是PB 9或更高版本，则可以generate COM or .NET dlls，然后您可以通过C＃GUI使用它。我建议用任何新语言重写。
请记住，重写永远不是一颗银弹，它们总是比你最初期望的更耗时，更困难，更多。
答案 3 :(得分：3)
您可能需要花一些时间来调查PowerBuilder 11.5（最近发布），这会增加一些重要的.NET集成。
迁移到PowerBuilder 11.5以便使用新的.NET代码肯定比在C＃中完全重写整个应用程序容易得多。
答案 4 :(得分：3)
我不知道它是否好，但请查看此（商业）产品：PB.Net
答案 5 :(得分：3)
本周的宠物理论是PowerBuilder开发人员将DataWindow视为理所当然，直到他们必须重现内置的所有功能。
我支持这个理论。几年前，我尝试将一个项目从PB8转换为Java，即使使用第一代HTML DataWindow也失败了。我现在的雇主一心想要转向C＃，尽管不使用Datawindow.NET。我们当前产品中的2K DWO。我不期待实现的那一天。（整个产品包括几个用户应用程序，十几个服务，并使用大约70个PBD）
OP - 除非您的应用程序结构异常结构（最初是为EA Server编写的？），否则这不是端口。在PB＆amp; .NET环境使普通端口能够令人满意地工作。我不能强调这一点 - 如果你真的使用PB事件模型，“端口”可能会失败。
您需要查看逻辑流程（交织的UI和流程），控制流程（谁拥有流程或数据现在），数据访问（UI，数据层，??）和您从代码中使用的DW事件模型的各个部分。如果您正在考虑ASP.NET（就像我们一样），您的整个用户交互体验将不得不改变，这将反馈到其他考虑因素。
与代码没有直接关系，构建自动化将发生变化（我们使用PowerGen实现一致的PB构建; MSBuild非常不同），您的安装和安装也是如此。设置。
答案 6 :(得分：3)
我认为任何考虑将其用于大型应用的人都会非常疯狂，不要非常认真考虑使用DataWindow.NET，以免失去对DW的投资。
答案 7 :(得分：3)
大公司的PHB认为Powerbuilder是一种玩具语言，并且迁移到像C＃这样的新语言是微不足道的，并且可以以低成本完成。实际上，将PB应用程序迁移到任何其他语言所花费的成本至少与在新语言上开发全新应用程序一样多。生成的应用程序通常会丢失与原始应用程序相比的功能，并会导致用户不满意。我已经看到了许多尝试 - 由于困难和用户问题，所有尝试都失败了。
如果没有损坏，请不要修复它。
答案 8 :(得分：0)
是的，如果没有重写服务组件的时间段，它现在可行。
PB 12.5＆gt;
将目标GUI和服务组件迁移和集成到c＃。
迁移/集成策略可能因项目范围，可伸缩性，资源和时间线而异。
您可以在PowerBuilder .NET中使用这些目标和项目类型。 请参阅此链接Sybase_PB .Net
