我公司已经使用Visual C ++中的MFC作为UI开发的实际标准开发了长期的产品。我们的代码库包含许多必须保持可操作性的旧代码/旧代码。其中一些代码比我更早(最初写于70年代末)，我们团队的某些成员仍在Visual Studio 6上。

但是，值得庆幸的是，内部已经得出结论，与竞争对手的产品相比，我们的产品看上去有些过时了，需要采取一些措施。

我目前正在研究UI的新区域，该区域与产品的其余部分完全分开。因此，在漫长的整个UI过渡过程开始之前，我就有机会尝试"新"技术栈作为一种试验场。

我在业余时间一直在使用Cwith Windows Forms和.net框架并享受它，但是有些担心互操作性引起的麻烦。尽管UI的这一特定分支不需要与旧版C ++代码库进行互操作，但我可以预见，这将在将来成为一个问题。

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

那么，我该选哪个呢？我们是一个很小的团队，所以我的建议很可能会被接受，这是我们想要正确发展的未来方向。

MFC死了吗？ C＃/ Winforms是前进的方向吗？我还有其他什么想念的吗？帮助极大的赞赏！

解决方案

回答

如果我们要考虑迁移到Cand因此，.NET，我会考虑使用Windows Presentation Foundation而不是WinForms。 WPF是.NET中智能客户端的未来，如果我们要制作由浏览器托管的Silverlight应用程序，则掌握的技能将可以重用。

回答

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

我想我们也必须考虑团队，如果当前的Cskills很少，那是一个因素，但是MFC开发人员的市场正在减少，Cis也在增长。

也许某种零碎的方法可能吗？我曾经参与过一些将旧应用程序重新编码为Cquite的工作，它总是花费比我们估计的时间长得多的时间，特别是如果我们保留一些旧代码，或者团队对C＃不太熟悉。

回答

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

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

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

回答

我们没有提供有关遗留代码的功能或者结构的详细信息。如果我们有特定的性能标准，则可能需要使用C ++维护一些代码库。如果可以正确的方式公开旧代码，那么我们可以更轻松地与旧代码进行互操作，我们可以从Ctoday调用现有代码库吗？可能值得考虑一个使该结构正确的项目。

关于WPF，我们可以争辩说WinForms可能更合适。迁移到WinForms对我们和团队而言是重要的一步。也许他们对转用WinForms可能更满意？如果我们仍然需要支持Windows 2000客户端，它的文档记录更好，在市场上具有更多的经验，并且非常有用。

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

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

回答

谢谢大家的答复，令人放心的是，总体而言，共识遵循了我的想法。我很幸运，我们的软件还可以在我们自己的定制硬件(用于广播行业)上运行，因此操作系统的选择确实是我们的，并直接给了客户。当前，我们正在运行XP / 2000，但是我可以看到很快升级到Vista的愿望。

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

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

看起来像Winforms，现在就喜欢它。

回答

我是一个拥有大量旧版MFC代码的应用程序的开发人员，我们同样关心我们。我们策略的主要推动力是尽可能地消除风险和不确定性，这意味着避免了The Big Rewrite。众所周知，TBR在大多数情况下都会失败。因此，我们选择了一种增量方法，该方法允许我们保留在当前版本中不会更改的模块，编写托管的新功能以及移植要增强的功能。

我们可以通过以下几种方法执行此操作：

• 在MFC视图上托管WPF内容(请参见此处)
• 对于MFC MDI应用程序，创建一个新的WinForms框架并托管MFC MDI视图(请参见此处)。
• 在MFC对话框和视图中托管WinForms用户控件(请参见此处)

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

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

第三种方法是我们选择的方法，并且效果很好。它使我们可以有选择地刷新应用程序的区域，同时保持整体一致性，并且不触碰没有损坏的地方。

Visual C ++ 2008 Feature Pack看起来很有趣，但是我还没有玩过。似乎可以解决我们过时的外观问题。如果"功能区"对于用户来说太麻烦了，我们可以看看第三方MFC和/或者WinForms控件供应商。

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

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