我的公司开发了一种使用Visual C ++中的MFC作为UI开发的事实标准的长期产品。我们的代码库包含大量遗留/古老代码，必须保持运行。其中一些代码比我早（最初写于70年代末期），我们团队的一些成员仍然在Visual Studio 6上。
然而，幸运的是，内部已经得出结论，与我们的竞争对手相比，我们的产品看起来有些陈旧，并且需要做些什么。
我目前正在开发UI的一个新区域，该区域与产品的其他部分完全分开。因此，我有机会尝试将“新”技术堆栈作为一种试验场，然后再开始移动UI的其余部分。
我在业余时间使用C＃和Windows Forms以及.net框架一段时间并享受它，但我有点担心互操作带来的麻烦。虽然UI的这个特定分支不需要与传统的C ++代码库很多互操作，但我可以预见这将成为未来的问题。
另一种方法是继续使用MFC，但尝试利用VS2008附带的新功能包。我想这是最简单的选择，但我担心长寿，而不是利用.net的优点......
那么，我选哪个？我们是一个小团队，所以我的建议很可能被接受为我们未来的发展方向 - 我想要做对。
MFC死了吗？ C＃/ Winforms是前进的方向吗？还有什么我完全不见了吗？非常感谢！
答案 0 :(得分：8)
我是一个拥有大量遗留MFC代码的应用程序的开发人员，我们也有同样的担忧。我们战略的一个重要推动因素是尽可能消除风险和不确定性，这意味着避免重大改写。众所周知，TBR大部分时间都失败了。因此，我们选择了一种增量方法，允许我们保留当前版本中不会发生变化的模块，编写管理的新功能，以及提升管理增强功能的功能。
您可以通过以下几种方式实现：
在您的MFC视图中托管WPF内容（请参阅here）
对于MFC MDI应用程序，创建一个新的WinForms框架并托管您的MFC MDI视图（请参阅here）
MFC对话框和视图中的主机WinForms用户控件（请参阅here）
采用WPF（选项1）的问题在于它需要您一次重写所有UI，否则它看起来会非常精神分裂。
第二种方法看起来可行但非常复杂。
第三种方法是我们选择的方法，它一直运作良好。它允许您有选择地刷新应用程序的区域，同时保持整体一致性，而不是触及未破坏的东西。
Visual C ++ 2008 Feature Pack看起来很有趣，但我还没有玩过它。看起来它可能有助于您的过时外观问题。如果“功能区”对您的用户来说过于刺耳，您可以查看第三方MFC和/或WinForms控件供应商。
我的总体建议是互操作+增量变化绝对比彻底改变更可取。
在阅读完后续文章后，我可以肯定地确认该框架的生产力增益远远超过了学习它的投资。我们团队中没有人在开始这项工作时使用过C＃，现在我们都更喜欢它。
答案 1 :(得分：2)
根据应用程序和客户安装.NET的意愿（并非所有这些都是），我肯定会转向WinForms或WPF。通过使用C ++ / CLI将非UI代码重构为类库（正如您在选择的标记中所述），大大简化了与C ++代码的互操作。
WPF的唯一问题是可能很难保持当前的外观。迁移到WinForms可以在保持GUI当前外观的同时完成。 WPF使用这样一个不同的模型，试图保持当前的布局可能是徒劳的，绝对不会符合WPF的精神。当多个WPF进程运行时，WPF在Vista之前的机器上表现也很差。
我的建议是找出您的客户正在使用的内容。如果大多数人已经转移到Vista并且您的团队准备投入大量GUI工作，我会说跳过WinForms并转移到WPF。否则，一定要认真看待WinForms。在任何一种情况下，C ++ / CLI中的类库都是您的互操作问题的答案。
答案 2 :(得分：2)
您没有详细说明遗留代码的功能或结构。如果您有某些性能标准，则可能需要在C ++中维护一些代码库。如果以正确的方式公开代码，您可以更轻松地与旧代码进行互操作 - 您今天可以调用现有的C＃代码库吗？可能值得考虑一个项目来使这个结构正确。
就WPF而言，你可以说WinForms可能更合适。迁移到WinForms对您和您的团队来说是一大步。也许他们可能更愿意转向WinForms？它有更好的文档记录，更多的市场经验，如果你仍然需要支持Windows 2000客户端，那就很有用。
您可能对Extending MFC Applications with the .NET Framework
感兴趣要考虑的其他事项是C++/CLI，但我没有相关经验。
答案 3 :(得分：2)
非常感谢你们的回复，我们可以放心地看到，一般来说，共识遵循我的思路。我很幸运，我们的软件也运行在我们自己的定制硬件上（用于广播行业） - 因此操作系统的选择确实是我们的，并且是我们的客户所追求的。目前我们正在运行XP / 2000，但我很快就会想到升级到Vista。
但是，我们还需要对GPU性能保持非常精细的控制，我猜这会自动排除WPF和硬件加速？我应该在原帖中说明这一点 - 对不起。也许可以使用两个GPU ......但这完全是另一个问题......
团队没有任何重要的C＃经验，我自己也不是专家，但我认为托管环境的整体长期优势可能超过了加快速度所需的时间。
现在看起来像Winforms和C＃。
答案 4 :(得分：1)
如果您考虑转向C＃，因此转向.NET，我会考虑使用Windows Presentation Foundation而不是WinForms。 WPF是.NET中智能客户端的未来，如果您想制作浏览器托管的Silverlight应用程序，您可以重复使用的技能。
答案 5 :(得分：0)
我同意WPF的观点。基于标记/ XML的UI似乎比WinForms更便携。
我猜你也必须考虑你的团队，如果没有很多当前的C＃技能，那么这是一个因素，但是MFC开发人员的市场正在逐渐减少，C＃正在增长。
也许某种零敲碎打的方法可能吗？我已经参与了将遗留应用程序重新编码到C＃中，并且它总是需要比你估计的要长很多，特别是如果你保留一些遗留代码，或者你的团队不熟悉C＃。