面向未来的大型UI应用程序 - 使用2008 Feature Pack的MFC,还是C#和Winforms？

我公司开发了一种使用Visual C++中的MFC作为UI开发的事实标准的长期产品.我们的代码库包含大量遗留/古老代码,必须保持运行.这些代码中的一些比我早(最初写于70年代末期),我们团队的一些成员仍在使用Visual Studio 6.

然而,幸运的是,内部已经得出结论,与竞争对手相比,我们的产品看起来有些陈旧,并且需要做些什么.

我目前正在开发UI的一个新领域,它与产品的其他部分完全不同.因此,我有机会尝试将"新"技术堆栈作为一种试验场,然后再开始移动UI的其余部分.

我在业余时间使用C#和Windows Forms以及.net框架一段时间并享受它,但我有点担心互操作引起的麻烦.虽然UI的这个特定分支不需要与传统的C++代码库很多互操作,但我可以预见这将成为未来的问题.

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

那么,我选哪个？我们是一个小团队,所以我的建议很可能被接受为我们未来的发展方向 - 我希望能够做到这一点.

MFC死了吗？C#/ Winforms是前进的方向吗？还有什么我完全不见了吗？非常感谢!

我是一个拥有大量遗留MFC代码的应用程序的开发人员,我们也有同样的担忧.我们战略的一个重要推动因素是尽可能消除风险和不确定性,这意味着避免重大改写.众所周知,TBR大部分时间都失败了.因此,我们选择了一种增量方法,允许我们保留当前版本中不会发生变化的模块,编写管理的新功能,以及提升受管增强功能的功能.

您可以通过以下几种方式实现:

在MFC视图上托管WPF内容(请参阅此处)

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

MFC对话框和视图中的主机WinForms用户控件(请参见此处)

采用WPF(选项1)的问题在于它需要您一次性重写所有UI,否则它看起来会非常精神分裂.

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

第三种方法是我们选择的方法,它一直运作良好.它允许您有选择地刷新应用程序的区域,同时保持整体一致性,而不是触及未破坏的东西.

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

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

在阅读完后续文章后,我可以肯定地证实,框架的生产率提高远远超过了学习它的投资.我们团队中没有人在开始这项工作时使用过C#,现在我们都更喜欢它.