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

Future proofing a large UI Application - MFC with 2008 Feature pack, or C# and Winforms?

提问by Ali Parr

My company has developed a long standing product using MFC in Visual C++ as the defacto standard for UI development. Our codebase contains ALOT of legacy/archaic code which must be kept operational. Some of this code is older than me (originally written in the late 70s) and some members of our team are still on Visual Studio 6.

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

However, a conclusion has thankfully been reached internally that our product is looking somewhat antiquated compared to our competitors', and that something needs to be done.

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

I am currently working on a new area of the UI which is quite separate from the rest of the product. I have therefore been given the chance to try out 'new' technology stacks as a sort of proving ground before the long process of moving over the rest of the UI begins.

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

I have been using C# with Windows Forms and the .net framework for a while in my spare time and enjoy it, but am somewhat worried about the headaches caused by interop. While this particular branch of the UI won't require much interop with the legacy C++ codebase, I can forsee this becoming an issue in the future.

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

The alternative is just to continue with MFC, but try and take advantage of the new feature pack that shipped with VS2008. This I guess is the easiest option, but I worry about longevity and not taking advantage of the goodness that is .net...

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

So, which do I pick? We're a small team so my recommendation will quite probably be accepted as a future direction for our development - I want to get it right.

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

Is MFC dead? Is C#/Winforms the way forward? Is there anything else I'm totally missing? Help greatly appreciated!

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

采纳答案by Aidan Ryan

I'm a developer on an app that has a ton of legacy MFC code, and we have all of your same concerns. A big driver for our strategy was to eliminate as much risk and uncertainty as we could, which meant avoiding The Big Rewrite. As we all know, TBR fails most of the time. So we chose an incremental approach that allows us to preserve modules that won't be changing in the current release, writing new features managed, andporting features that are getting enhancements to managed.

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

You can do this several ways:

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

1. Host WPF content on your MFC views (see here)

2. For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)

3. Host WinForms user controls in MFC Dialogs and Views (see here)

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

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

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

The problem with adopting WPF (option 1) is that it will require you to rewrite all of your UI at once, otherwise it'll look pretty schizophrenic.

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

The second approach looks viable but very complicated.

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

The third approach is the one we selected and it's been working very well. It allows you to selectively refresh areas of your app while maintaining overall consistency and not touching things that aren't broken.

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

The Visual C++ 2008 Feature Pack looks interesting, I haven't played with it though. Seems like it might help with your issue of outdated look. If the "ribbon" would be too jarring for your users you could look at third-party MFC and/or WinForms control vendors.

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

My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.

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

---

---

After reading your follow-up, I can definitely confirm that the productivity gains of the framework vastly outweigh the investment in learning it. Nobody on our team had used C# at the start of this effort and now we all prefer it.

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

回答by Matt Hamilton

Were you to look at moving to C# and therefore .NET, I would consider Windows Presentation Foundation rather than WinForms. WPF is the future of smart clients in .NET, and the skills you pick up you'll be able to reuse if you want to make browser-hosted Silverlight applications.

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

回答by JamesSugrue

I concur with the WPF sentiment. Tag/XML based UI would seem to be a bit more portable than WinForms.

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

I guess too you have to consider your team, if there is not a lot of current C# skills, then that is a factor, but going forward the market for MFC developers is diminishing and C# is growing.

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

Maybe some kind of piecemeal approach would be possible? I have been involved with recoding legacy applications to C# quite a bit, and it always takes a lot longer than you would estimate, especially if you are keeping some legacy code, or your team isn't that conversant with C#.

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

回答by Zooba

Depending on the application and the willingness of your customers to install .NET (not all of them are), I would definitely move to WinForms or WPF. Interop with C++ code is hugely simplified by refactoring non-UI code into class libraries using C++/CLI (as you've noted in your selection of tags).

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

The only issue with WPF is that it may be hard to maintain the current look-and-feel. Moving to WinForms can be done while maintaining the current look of your GUI. WPF uses such a different model that to attempt to keep the current layout would probably be futile and would definitely not be in the spirit of WPF. WPF also apparently has poor performance on pre-Vista machines when more than one WPF process is running.

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

My suggestion is to find out what your clients are using. If most have moved to Vista and your team is prepared to put in a lot of GUI work, I would say skip WinForms and move to WPF. Otherwise, definitely look seriously at WinForms. In either case, a class library in C++/CLI is the answer to your interop concerns.

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

回答by Brian Lyttle

You don't give a lot of detail on what your legacy code does or how it's structured. If you have certain performance criteria you might want to maintain some of your codebase in C++. You'll have an easier time doing interop with your old code if it is exposed in the right way - can you call into the existing codebase from C# today? Might be worth thinking about a project to get this structure right.

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

On the point of WPF, you could argue that WinForms may be more appropriate. Moving to WinForms is a big step for you and your team. Perhaps they may be more comfortable with the move to WinForms? It's better documented, more experience in the market, and useful if you still need to support windows 2000 clients.

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

You might be interested in Extending MFC Applications with the .NET Framework

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

Something else to consider is C++/CLI, but I don't have experience with it.

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

回答by Ali Parr

Thank you all kindly for your responses, it's reassuring to see that generally the consensus follows my line of thinking. I am in the fortunate situation that our software also runs on our own custom hardware (for the broadcast industry) - so the choice of OS is really ours and is thrust upon our customers. Currently we're running XP/2000, but I can see a desire to move up to Vista soon.

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

However, we also need to maintain very fine control over GPU performance, which I guess automatically rules out WPF and hardware acceleration? I should have made that point in my original post - sorry. Perhaps it's possible to use two GPUs... but that's another question altogether...

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

The team doesn't have any significant C# experience and I'm no expert myself, but I think the overall long term benefits of a managed environment probably outweigh the time it'll take to get up to speed.

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

Looks like Winforms and C# have it for now.

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