12

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

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

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

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

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

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

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

4

6 回答 6

8

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

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

  1. 在 MFC 视图上托管 WPF 内容（请参见此处）

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

  3. 在 MFC 对话框和视图中托管 WinForms 用户控件（请参阅此处）

采用 WPF（选项 1）的问题在于，它需要您一次重写所有 UI，否则它看起来会让人精神分裂。

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

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

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

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

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

于 2008-08-14T13:32:29.810 回答
2

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

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

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

于 2008-08-14T11:40:53.373 回答
2

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

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

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

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

于 2008-08-14T12:04:56.460 回答
2

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

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

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

看起来像 Winforms 和 C# 现在有它。

于 2008-08-14T13:30:47.177 回答
1

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

于 2008-08-14T11:28:23.570 回答
0

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

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

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

于 2008-08-14T11:36:47.173 回答