面向未来的大型UI应用程序-带2008功能包的MFC,还是C和WinForms?

我是一个应用程序的开发人员,这个应用程序有大量遗留的MFC代码,我们也有你同样的担心。我们战略的一个重要驱动力是尽可能消除风险和不确定性,这意味着要避免大的重写。众所周知,TBR在大多数情况下都会失败。因此,我们选择了一种增量方法,它允许我们保留在当前版本中不会改变的模块,编写新的托管功能,以及移植将增强功能转化为托管功能的功能。

您可以通过以下几种方式进行此操作:

1. 在MFC视图上承载WPF内容(请参见 here )

2. 对于MFC MDI应用程序,创建一个新的WinForms框架并托管您的MFC MDI视图(请参见 here )

3. 在MFC对话框和视图中宿主WinForms用户控件(请参见 here )

采用WPF(选项1)的问题是,它将要求您一次重写所有的UI,否则它看起来很精神分裂。

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

第三种方法是我们选择的方法,它运行得很好。它允许你有选择地刷新你的应用程序的区域,同时保持整体的一致性,不接触那些没有被破坏的东西。

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

我的总体建议是,互操作+增量更改肯定比全面更改更可取。

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

根据您的应用程序和客户安装.NET的意愿(并非所有客户都是这样),我肯定会转向WinForms或WPF。使用C++代码将互不相关的UI代码转换成类库,从而大大简化了C++代码的互操作(如您在标签选择中所注意到的)。

WPF唯一的问题是它可能很难保持当前的外观和感觉。移动到WinForms可以在保持图形用户界面当前外观的同时完成。WPF使用了这样一种不同的模型,试图保持当前的布局可能是徒劳的,并且绝对不会符合WPF的精神。显然,当多个WPF进程运行时,WPF在Vista之前的计算机上的性能也很差。

我的建议是找出你的客户在使用什么。如果大多数人已经转移到了Vista,并且您的团队已经准备好投入大量的GUI工作,我会说跳过WinForms并转移到WPF。否则,一定要认真对待Winforms。在这两种情况下,C++/CLI中的类库都是您的互操作问题的答案。

对于遗留代码的功能和结构,您不会给出太多细节。如果您有某些性能标准,您可能希望在C++中维护一些代码库。如果旧代码以正确的方式公开,那么您可以更轻松地与它进行互操作—您今天可以从C调用现有的代码库吗?可能值得考虑一个项目来使这个结构正确。

就WPF而言,您可以认为WinForms可能更合适。对于您和您的团队来说,迁移到WinForms是一个很大的步骤。也许他们会更愿意搬到WinForms?它有更好的文档记录,在市场上有更多的经验,如果您仍然需要支持Windows2000客户机,它会很有用。

你可能对 Extending MFC Applications with the .NET Framework

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

谢谢大家的回答,看到大家的共识大体上都遵循我的思路,我感到很放心。我很幸运,我们的软件也运行在我们自己的定制硬件上(为广播行业),所以操作系统的选择是我们的,并且是我们的客户的责任。目前我们正在运行XP/2000,但我可以看到很快就要升级到Vista。

但是,我们还需要对GPU性能保持非常精细的控制,我想这会自动排除WPF和硬件加速?我本该在我原来的帖子里指出这一点的-对不起。也许可以使用两个GPU…但这是另外一个问题…

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

看起来像Winforms和C暂时拥有它。

如果你想移动到C.*和.NET,我会考虑Windows演示基础而不是WINFALSE。WPF是.NET中智能客户端的未来,如果您想使浏览器托管的Silverlight应用程序能够重用您学到的技能。

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

我想你也必须考虑你的团队,如果目前没有太多的C技能,那么这是一个因素,但未来的MFC开发者市场正在减少,C正在增长。

也许某种零碎的方法是可能的?我曾经参与过将遗留应用程序重新编码到C的工作,而且它总是比您估计的要长得多,尤其是如果您保留了一些遗留代码,或者您的团队不太熟悉C。