MigratingaPowerBuilderApplicationto.NET有人对将PowerBuilder10业务应用程序迁移到.NET有任何建议吗？我的公司正在考虑将遗留的PB应用程序迁移到.NET(C#)，我只是想知道是否有人有任何经验-好的或坏的-你愿意分享。该应用程序非常大，包含10个PBL库、一些PFC和一个自定义框架。还有大量的DLL调用。最后，它使用MicrosoftSQLServer数据库。我们讨论了将“核心”应用程序代码移植到.NET，然后根据需要移植更高级的功能。当我看到这个标题时，我只是潜伏着，作为一个著名的PB偏执狂。那好吧。感谢伯纳德的信任投票。我的第一个建议是放弃自欺欺人的语言。如果我吃了半个“精简版”芝士蛋糕，我仍然看不到我的腰带。迁移只需10分钟。您所要做的就是重写.时间需要作为重写来衡量。风险需要作为重写来衡量。设计工作应该作为重写来衡量。是的，我说的是设计工作。“迁移”通过一些黑盒子让人联想到泵代码的图像，翻译成原始图像的另一面。您是否想重蹈1994年的覆辙？即使有好的代码，我猜想在PowerBuilder中一个好的设计选择在C#中可能是一个糟糕的设计选择。直接切换会忽略平台的力量吗？在接下来的15年里，您会因为忽视良好的C#设计而遭受后果吗？除此之外，由于您没有提到迁移到“.NET”的动机，因此很难说您可能有哪些选择来降低重写的风险。如果您的管理层只是认为PowerBuilder开发人员闻起来很臭并且需要从办公室撤职，那么祝您重写好运。如果您只是想部署Windows窗体、Web窗体、程序集或.NETWeb服务，或者利用.NET库，那么正如Paul提到的那样，迁移到11.0或11.5可以帮助您实现目标。（我建议仔细检查并确保您已经为新平台设计了良好的设计，尤其是Web窗体，但这种努力应该比重写小得多。）如果您想部署WPF应用程序，我知道一年是等待很长时间，但可能值得研究PowerBuilder12。适当地提取，WPF功能可能会使PowerBuilder处于独特而强大的位置。如果将来需要重写（淋浴看起来更便宜），您可能需要逐步进行转换。DataWindow.NET使您可以随身携带DataWindow。（我本周最喜欢的理论是，PowerBuilder开发人员认为DataWindow是理所当然的，直到他们必须重现所有内置功能。）能够放弃预先存在的、预先测试的、多行的、可滚动的、最小的资源消耗、可打印、数据绑定的动态UI、最少的SQL生成、用于记录锁定和将数据库错误转换为事件的内置逻辑，是进入新应用程序的一个大问题。您还可以通过将PowerBuilder代码转换为.NET应用程序可以使用的代码来暂存转换。如上所述，您可以使用现有的PB10生成COM对象，但您必须迁移到11.0或11.5才能生成程序集。该值可能取决于您的应用程序的分区方式。如果您的业务逻辑通过GUI事件和函数进行窃取而不是划分为非可视对象（也称为自定义类），则此值可能会出现问题。不过，这是一个设计错误，应该在完全转换为C#之前修复；这可以在将PowerBuilder应用程序作为分阶段然后完全转换的初步步骤的同时完成。毫无疑问，我宁愿看到你留在PowerBuilder。如果做不到这一点，我希望看到你成功。请记住，一旦咬下第一口，就必须吃完。祝你找到腰带好运，特里。我看到您提到首先将“核心组件”移至.NET。你现在可能已经猜到了，我认为分阶段的方法是一个明智的决定。现在，“核心”的定义可能有争议，但反对意见又如何。周到？（显然，这周开始节食是错误的。）鉴于PB现在所处的位置，很难根据应用程序功能（例如PB中的应收帐款，C#帐户中的应付帐款）来划分PB和C#之间的应用程序。可能工作的部门是GUI与业务逻辑。如前所述，已经可以将业务逻辑从PB提取到C#可以使用的可执行文件中。我如何在C#中构建GUI，从PB复制数据窗口并将业务逻辑提取为COM对象或程序集？换句话说，要在PB中使用.NET程序集，您要么必须升级到11.x并迁移到Windows窗体，要么将它们放入COM可调用包装器中。或者，只需在PowerBuilder中培训您的C#开发人员。这可能只是一个谣言，但我听说新的PowerBuilder营销标签将是“如此简单，甚至C#开发人员都可以使用它”。？我认为gbjbaanb给了你一个很好的答案。？其他一些需要考虑的事情：如果软件非常糟糕并对公司的业务产生负面影响，我不反对重写，但即使这样，渐进式调整和改进也是一种风险较小的系统发展方式。另外，在TerryVoth发布之前不要放弃这篇文章。他是StackOverflow上的顶级PB之一。如果它相当大，您可能会在.net（或基于Web的GUI）中为它编写前端并使用它与您的PB代码交互，假设您可以将其作为API公开，那么您可能会获得更好的结果。如果您使用的是PB9或更高版本，则可以生成COM或.NETdll，然后可以通过C#GUI使用它们。我建议用任何新语言重写。请记住，重写从来都不是灵丹妙药，它们总是比您最初预期的更耗时、更困难、更复杂。您可能想花一些时间深入研究PowerBuilder11.5（最近发布），它增加了一些重要的.NET集成。迁移到PowerBuilder11.5以使用新的.NET代码当然比用C#完全重写整个应用程序要容易得多。我不知道它是否好，但是检查这个（商业）产品：PB.Net我本周最喜欢的理论是PowerBuilder开发人员认为DataWindow是理所当然的，直到他们必须重现所有内置功能。我支持这个理论.几年前，我在一个项目中试图从PB8转换为Java，即使使用第一代HTMLDataWindow，它仍然失败。我现在的雇主非常热衷于转向C#，虽然我们目前的产品中有超过2000个DWO，但Datawindow.NET不是。我不期待那一天。（整个产品由几个用户应用程序、十几个服务组成，并使用了大约70个PBD）OP-除非您的应用程序结构非常出色（它最初是为EAServer编写的吗？），否则这不是一个端口。在PB和.NET环境中，事情的工作方式完全不同，因此普通端口可以令人满意地工作。我怎么强调都不为过——如果你真的使用PB事件模型，“端口”可能会失败。您需要查看逻辑流（UI和流交织在一起）、控制流（谁现在拥有流程或数据）、数据访问（UI、数据层、??）以及您正在使用的DW事件模型部分代码。如果您正在考虑ASP.NET（就像我们一样），您的整个用户交互体验将不得不改变，这将反馈到其他考虑因素中。与代码没有直接关系，构建自动化会发生变化（我们使用PowerGen进行一致的PB构建；MSBuild非常不同），您的安装和设置也会发生变化。我认为任何想将它用于大型应用程序的人都会非常疯狂，而不是非常认真地考虑使用DataWindow.NET，以免他们失去对DW的投资。大公司的PHB认为Powerbuilder是一种玩具语言，迁移到像C#这样的新语言是微不足道的，并且可以以低成本完成。事实上，将PB应用程序迁移到任何其他语言的成本至少与在新语言上开发一个全新的应用程序一样多。与原始应用程序相比，生成的应用程序通常会失去功能，并会导致用户不满意。我见过很多尝试-由于困难和用户问题都失败了。如果它没有损坏，请不要修理它。是的，它现在无需重写服务组件周期即可工作。PB12.5>并将目标GUI和服务组件迁移并集成到c#。迁移/集成策略可能因项目范围、可扩展性、资源和时间表而异。您可以在PowerBuilder.NET中使用这些目标和项目类型。请参考这个链接Sybase_PB.Net以上就是C#学习教程：将PowerBuilder应用程序移植到.NET的全部内容。如果对你有用，需要了解更多C#学习教程，希望大家多多关注——本文来自网络收藏，不代表立场，如涉及侵权，请点击有权联系管理员删除。如需转载请注明出处：
