Future proofing a large UI Application - MFC with 2008 Feature pack, or C# and Winforms?我公司已经使用Visual C ++中的MFC作为UI开发的实际标准开发了长期的产品。我们的代码库包含许多必须保持可操作性的旧代码/旧代码。其中一些代码比我早(最初写于70年代后期)，而我们团队中的某些成员仍在Visual Studio 6上。 但是，值得庆幸的是，内部得出的结论是，与竞争对手的产品相比，我们的产品看上去有些过时了，需要做些事情。 我目前正在研究UI的新区域，该区域与产品的其余部分完全分开。因此，在漫长的整个UI过渡过程开始之前，我就有机会尝试"新"技术栈作为一种试验场。 在业余时间，我一直在将C＃与Windows Forms和.net框架一起使用，并乐在其中，但是有些担心由互操作引起的麻烦。尽管UI的这一特定分支不需要与旧版C ++代码库进行互操作，但我可以预见，这将在将来成为一个问题。 另一种选择是继续使用MFC，但尝试利用VS2008附带的新功能包。我猜这是最简单的选择，但是我担心寿命长，并且没有利用.net的优点。 那么，我该选哪个呢？我们是一个很小的团队，所以我的建议很可能会被接受为我们发展的未来方向-我想做对。 MFC死了吗？ C＃/ Winforms是前进的方向吗？我还有其他什么想念的吗？帮助极大的赞赏！ 我是一个应用程序的开发人员，该应用程序具有大量的遗留MFC代码，我们同样关心您。我们策略的主要推动力是尽可能地消除风险和不确定性，这意味着避免了The Big Rewrite。众所周知，TBR大多数时候都会失败。因此，我们选择了一种增量方法，该方法允许我们保留在当前版本中不会更改的模块，编写受管理的新功能以及移植将要增强的功能。 您可以通过以下几种方法执行此操作： 在MFC视图上托管WPF内容(请参见此处) 对于MFC MDI应用程序，创建一个新的WinForms框架并托管您的MFC MDI视图(请参见此处)。 在MFC对话框和视图中托管WinForms用户控件(请参见此处) 采用WPF(选项1)的问题在于，它将要求您立即重写所有UI，否则看起来会精神分裂。 第二种方法看起来可行，但非常复杂。 第三种方法是我们选择的方法，并且效果很好。它使您可以有选择地刷新应用程序的区域，同时保持整体一致性，并且不触碰没有损坏的地方。 Visual C ++ 2008 Feature Pack看起来很有趣，但是我还没有玩过。似乎可以解决您过时的外观问题。如果"功能区"对于您的用户来说太麻烦了，您可以考虑使用第三方MFC和/或WinForms控件供应商。 我的总体建议是互操作+增量更改绝对比全面更改更可取。 阅读您的后续文章后，我可以肯定地确认该框架的生产率收益大大超过了学习该框架的投资。在开始这项工作时，我们团队中没有人使用过C＃，现在我们所有人都更喜欢它。 谢谢大家的答复，令人放心的是，总体而言，共识遵循了我的想法。幸运的是，我们的软件还可以在我们自己的定制硬件(用于广播行业)上运行-因此，操作系统的选择确实是我们的选择，并直接针对我们的客户。当前，我们正在运行XP / 2000，但我可以看到很快升级到Vista的愿望。 但是，我们还需要对GPU性能保持非常精细的控制，我想这会自动排除WPF和硬件加速吗？我应该在我的原始帖子中提到这一点-抱歉。也许可以使用两个GPU ...但这是另一个问题... 该团队没有任何重要的C＃经验，而且我自己也不是专家，但是我认为托管环境的总体长期利益可能超过了加快速度所需要的时间。 看起来Winforms和C＃暂时拥有它。 您没有提供有关遗留代码的功能或结构的详细信息。如果您具有某些性能标准，则可能需要使用C ++维护一些代码库。如果以正确的方式公开您的旧代码，您将可以更轻松地进行互操作-您今天可以从C＃调用现有代码库吗？可能值得考虑一个使该结构正确的项目。 关于WPF，您可以争辩说WinForms可能更合适。迁移到WinForms对您和您的团队而言是重要的一步。也许他们对使用WinForms可能更满意？如果您仍然需要支持Windows 2000客户端，它的文档记录更好，在市场上具有更多的经验，并且非常有用。 您可能对使用.NET Framework扩展MFC应用程序感兴趣 其他要考虑的是C ++ / CLI，但是我没有经验。 根据应用程序和客户安装.NET的意愿(并非所有人都愿意)，我肯定会使用WinForms或WPF。通过使用C ++ / CLI将非UI代码重构到类库中，可以极大地简化与C ++代码的互操作(正如您在选择标记中所指出的)。 WPF的唯一问题是可能很难维持当前的外观。可以在保持GUI当前外观的同时完成向WinForms的迁移。 WPF使用了不同的模型，试图保持当前的布局可能是徒劳的，而且绝对不符合WPF的精神。当运行多个WPF进程时，WPF在Vista之前的计算机上的性能显然也很差。 我的建议是找出您的客户正在使用什么。如果大多数人已经迁移到Vista，并且您的团队准备进行很多GUI工作，那么我想说跳过WinForms并转到WPF。否则，一定要认真看一下WinForms。无论哪种情况，C ++ / CLI中的类库都可以解决您的互操作问题。 如果您要考虑迁移到C＃和.NET，我会考虑使用Windows Presentation Foundation而不是WinForms。 WPF是.NET中智能客户端的未来，如果您要制作由浏览器托管的Silverlight应用程序，则掌握的技能将可以重用。 我同意WPF的观点。基于标记/ XML的UI似乎比WinForms更可移植。 我想您也必须考虑您的团队，如果当前的C＃技能不多，那是一个因素，但是MFC开发人员的市场在不断缩小，C＃也在增长。 也许某种零碎的方法可能吗？我参与了将旧应用程序重新编码为C＃的工作，并且花费的时间总是比您估计的要长得多，尤其是如果您保留一些旧代码，或者您的团队对C＃不太熟悉。 |
