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

Question

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

然而，值得庆幸的是，内部得出的结论是，与竞争对手的产品相比，我们的产品看起来有些过时，需要采取一些措施。

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

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

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

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

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

Answer 1

我是一名应用程序开发人员，该应用程序拥有大量遗留 MFC 代码，我们也有您同样的担忧。我们战略的一个重要驱动力是尽可能消除风险和不确定性，这意味着避免大重写。众所周知，TBR大多数时候都会失败。因此，我们选择了一种增量方法，允许我们保留在当前版本中不会更改的模块，编写托管的新功能，并将增强的功能移植到托管。

您可以通过多种方式执行此操作：

1. 在 MFC 视图上托管 WPF 内容（请参阅 这里)

2. 对于 MFC MDI 应用程序，创建一个新的 WinForms 框架并托管 MFC MDI 视图（请参阅 这里)

3. 在 MFC 对话框和视图中托管 WinForms 用户控件（请参阅 这里)

采用 WPF（选项 1）的问题在于，它将要求您立即重写所有 UI，否则看起来会很精神分裂。

第二种方法看起来可行，但非常复杂。

我们选择了第三种方法，并且效果非常好。它允许您有选择地刷新应用程序的区域，同时保持整体一致性并且不触及未损坏的内容。

Visual C++ 2008 功能包看起来很有趣，但我还没玩过。看起来它可能有助于解决您过时的外观问题。如果“功能区”对您的用户来说太刺耳，您可以考虑第三方 MFC 和/或 WinForms 控件供应商。

我的总体建议是，互操作+增量更改绝对比全面更改更可取。

---

阅读您的后续文章后，我可以肯定地确认该框架的生产力收益远远超过学习它的投资。在这项工作开始时，我们团队中没有人使用过 C#，现在我们都更喜欢它。

Answer 2

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

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

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

Answer 3

您没有提供有关遗留代码的用途或结构的详细信息。如果您有一定的性能标准，您可能希望用 C++ 维护一些代码库。如果以正确的方式公开旧代码，您将可以更轻松地与旧代码进行互操作 - 您今天可以从 C# 调用现有代码库吗？可能值得考虑一个项目来使这个结构正确。

就 WPF 而言，您可能会认为 WinForms 可能更合适。迁移到 WinForms 对您和您的团队来说是一大进步。也许他们更愿意迁移到 WinForms？它有更好的文档、更多的市场经验，并且如果您仍然需要支持 Windows 2000 客户端，那么它会非常有用。

您可能感兴趣 使用 .NET Framework 扩展 MFC 应用程序

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

Answer 4

非常感谢大家的回复，看到大家的共识总体上符合我的思路，我感到很欣慰。我很幸运，我们的软件也可以在我们自己的定制硬件（针对广播行业）上运行 - 因此操作系统的选择实际上是我们的，并且强加给我们的客户。目前我们正在运行 XP/2000，但我可以看到很快升级到 Vista 的愿望。

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

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

看起来 Winforms 和 C# 目前已经有了。

Answer 5

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

Answer 6

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

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

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