面向未来的大型 UI 应用程序 - 带有 2008 功能包的 MFC，还是 C# 和 Winforms? [英] Future proofing a large UI Application - MFC with 2008 Feature pack, or C# and Winforms?
问题描述
我的公司开发了一个长期使用的产品，它使用 Visual C++ 中的 MFC 作为 UI 开发的事实标准.我们的代码库包含大量必须保持可操作的遗留/过时代码.其中一些代码比我更老(最初写于 70 年代后期)，我们团队的一些成员仍在使用 Visual Studio 6.
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.
但是，幸运的是，内部得出的结论是，与竞争对手的产品相比，我们的产品看起来有些过时，需要做点什么.
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.
我目前正在开发 UI 的一个新区域，该区域与产品的其他部分完全不同.因此，我有机会在 UI 其余部分的漫长过程开始之前尝试新"技术堆栈作为一种试验场.
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.
我在业余时间一直在使用 C# 与 Windows 窗体和 .net 框架并享受它，但我有点担心互操作带来的头痛.虽然 UI 的这个特定分支不需要与传统 C++ 代码库进行太多互操作，但我可以预见这将成为未来的一个问题.
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.
另一种方法是继续使用 MFC，但尝试利用 VS2008 附带的新功能包.我想这是最简单的选择，但我担心寿命长而不是利用 .net 的优点......
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...
那么，我该选哪个?我们是一个小团队，所以我的建议很可能会被接受，作为我们未来发展的方向 - 我想把它做好.
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.
MFC 死了吗?C#/Winforms 是前进的方向吗?还有什么我完全想念的吗?非常感谢您的帮助！
Is MFC dead? Is C#/Winforms the way forward? Is there anything else I'm totally missing? Help greatly appreciated!
推荐答案
我是一个拥有大量遗留 MFC 代码的应用程序的开发人员，我们也有你同样的担忧.我们战略的一个重要推动力是尽可能多地消除风险和不确定性，这意味着避免大重写.众所周知，TBR 大部分时间都失败了.因此，我们选择了一种增量方法，允许我们保留在当前版本中不会更改的模块，编写托管的新功能，并移植正在增强托管的功能.
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.
您可以通过多种方式做到这一点:
You can do this several ways:
在 MFC 视图上托管 WPF 内容(请参阅 这里)
对于 MFC MDI 应用程序，创建一个新的 WinForms 框架并托管您的 MFC MDI 视图(请参阅 这里)
For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)
在 MFC 对话框和视图中托管 WinForms 用户控件(请参阅 此处)
Host WinForms user controls in MFC Dialogs and Views (see here)
采用 WPF(选项 1)的问题在于，它需要您一次重写所有 UI，否则看起来会让人精神分裂.
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.
第二种方法看起来可行但非常复杂.
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.
Visual C++ 2008 Feature Pack 看起来很有趣，不过我还没有玩过它.似乎它可能有助于解决您过时的外观问题.如果功能区"对您的用户来说过于刺耳，您可以查看第三方 MFC 和/或 WinForms 控件供应商.
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.
我的总体建议是互操作 + 增量更改绝对比全面更改更可取.
My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.
阅读您的后续文章后，我可以肯定地确认该框架的生产力收益大大超过了学习它的投资.我们团队中没有人在这项工作开始时使用过 C#，现在我们都更喜欢它.
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.
这篇关于面向未来的大型 UI 应用程序 - 带有 2008 功能包的 MFC，还是 C# 和 Winforms?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
