面向未来的大型 UI 应用程序 - 带有 2008 功能包的 MFC，还是 C# 和 Winforms？答案

【问题标题】：Future proofing a large UI Application - MFC with 2008 Feature pack, or C# and Winforms?面向未来的大型 UI 应用程序 - 带有 2008 功能包的 MFC，还是 C# 和 Winforms？
【发布时间】：2025-11-25 16:25:01
【问题描述】：

我的公司开发了一个长期使用的产品，它使用 Visual C++ 中的 MFC 作为 UI 开发的事实标准。我们的代码库包含大量必须保持可操作的遗留/过时代码。其中一些代码比我更老（最初写于 70 年代后期），我们团队的一些成员仍在使用 Visual Studio 6。

但是，幸运的是，内部得出的结论是，与竞争对手的产品相比，我们的产品看起来有些过时，需要做点什么。

我目前正在开发 UI 的一个新区域，该区域与产品的其他部分完全不同。因此，我有机会在 UI 其余部分的漫长过程开始之前尝试“新”技术堆栈作为一种试验场。

我在业余时间一直在使用 C# 与 Windows 窗体和 .net 框架并享受它，但我有点担心互操作带来的头痛。虽然 UI 的这个特定分支不需要与传统 C++ 代码库进行太多互操作，但我可以预见这将成为未来的一个问题。

另一种方法是继续使用 MFC，但尝试利用 VS2008 附带的新功能包。我想这是最简单的选择，但我担心寿命长而不是利用 .net 的优点......

那么，我该选哪个？我们是一个小团队，所以我的建议很可能会被接受，作为我们未来发展的方向 - 我想把它做好。

MFC 死了吗？ C#/Winforms 是前进的方向吗？还有什么我完全想念的吗？非常感谢您的帮助！

【问题讨论】：

是的，MFC 已死。 WinForms 正在消亡。在这一点上，前进的道路是 WPF。从 MFC 切换到 WinForms 将大大降低成本，但从 WinForms 转向 WPF 将大大降低成本。对于仍需要支持 Windows 2000 机器或 Windows Mobile 的人来说，WinForms 是一个不错的选择。 DirectX 仍然是 3D 游戏和 CAD 的最佳选择。恕我直言，其他所有人都应该完全跳过 WinForms，直接转向 WPF。

标签： c# c++ winforms mfc user-interface

【解决方案1】：

我是一个拥有大量遗留 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#，现在我们都更喜欢它。

【讨论】：

您可以为 WPF 设置主题，使其看起来像旧样式控件。
为此付出的努力/回报令人沮丧。更不用说你将永远让它看起来正确。你最终会得到“恐怖谷”效应。
获得像素完美的 WPF 样式可能需要很长时间，但在几个小时内，我能够获得如此准确的应用程序样式，以至于没有人 - 甚至包括 QA 人员 - 都意识到新部分稍微有点不同。

【解决方案2】：

根据应用程序和客户安装 .NET 的意愿（并非所有客户都安装），我肯定会转向 WinForms 或 WPF。通过使用 C++/CLI 将非 UI 代码重构为类库，极大地简化了与 C++ 代码的互操作（正如您在选择标签时所指出的那样）。

WPF 的唯一问题是可能很难保持当前的外观。可以在保持 GUI 的当前外观的同时迁移到 WinForms。 WPF 使用如此不同的模型，试图保持当前布局可能是徒劳的，而且绝对不符合 WPF 的精神。当运行多个 WPF 进程时，WPF 在 Vista 之前的机器上的性能显然也很差。

我的建议是了解您的客户正在使用什么。如果大多数人已经迁移到 Vista 并且您的团队准备投入大量 GUI 工作，我会说跳过 WinForms 并迁移到 WPF。否则，一定要认真看待 WinForms。无论哪种情况，C++/CLI 中的类库都可以解决您的互操作问题。

【讨论】：

请为多实例的 WPF 性能不佳提供参考 - 这可能是我们的关键问题！
Windows Vista 显示驱动程序模型 (msdn.microsoft.com/en-us/library/aa480220.aspx)，来自 MSDN
我的一台开发机器是双显示器 Windows XP，我经常在屏幕上看到几个 WPF 应用程序。我没有注意到任何性能问题。当然，我用于开发的应用程序都不是真正的具有大量移动对象的重型图形应用程序。如果是这种情况，GPU 共享问题可能会变得很明显。

【解决方案3】：

您没有详细说明遗留代码的功能或结构。如果您有某些性能标准，您可能希望在 C++ 中维护一些代码库。如果以正确的方式公开旧代码，您将更容易与旧代码进行互操作 - 您今天可以从 C# 调用现有代码库吗？可能值得考虑一个使这种结构正确的项目。

关于 WPF，您可能会争辩说 WinForms 可能更合适。迁移到 WinForms 对您和您的团队来说是一大步。也许他们可能更愿意迁移到 WinForms？如果您仍需要支持 Windows 2000 客户端，它会提供更好的文档、更多的市场经验和有用的信息。

你可能对Extending MFC Applications with the .NET Framework感兴趣

其他要考虑的是C++/CLI，但我没有这方面的经验。

【讨论】：

【解决方案4】：

非常感谢大家的回复，看到大家普遍达成的共识遵循我的思路，我感到很欣慰。我很幸运，我们的软件也可以在我们自己的定制硬件上运行（用于广播行业）——所以操作系统的选择实际上是我们的，并且是强加给我们的客户的。目前我们正在运行 XP/2000，但我可以看到希望尽快升级到 Vista。

但是，我们还需要对 GPU 性能保持非常精细的控制，我猜这会自动排除 WPF 和硬件加速？我应该在我原来的帖子中指出这一点——对不起。也许可以使用两个 GPU……但这完全是另一个问题……

该团队没有任何重要的 C# 经验，而且我自己也不是专家，但我认为托管环境的整体长期收益可能超过加快速度所需的时间。

看起来 Winforms 和 C# 现在已经有了它。

【讨论】：

GPU 似乎对 WPF 内存使用也有巨大影响。
我不知道这是否会影响您的情况，但至少有一种情况是在运行 WPF 时根本不使用 GPU：远程桌面（RDP / 终端服务）。更准确地说，远程机器的 GPU 在运行 WPF 应用程序时根本没有使用。在 RDP 6.0 下，原语被传回客户端进行渲染。

【解决方案5】：

如果您考虑迁移到 C# 并因此迁移到 .NET，我会考虑 Windows Presentation Foundation 而不是 WinForms。 WPF 是 .NET 中智能客户端的未来，如果您想制作浏览器托管的 Silverlight 应用程序，您将能够重用所掌握的技能。

【讨论】：

【解决方案6】：

我同意 WPF 的观点。基于标签/XML 的 UI 似乎比 WinForms 更便携。

我想你也必须考虑你的团队，如果当前没有很多 C# 技能，那么这是一个因素，但未来 MFC 开发人员的市场正在减少，而 C# 正在增长。

也许某种零散的方法是可能的？我参与了很多将遗留应用程序重新编码为 C# 的工作，而且它所花费的时间总是比您估计的要长得多，尤其是如果您保留一些遗留代码，或者您的团队不太熟悉 C#。

【讨论】：