17 *_* 26 29 .net c# c++ wpf mfc
我目前正在研究一个非常大的传统MFC MDI应用程序.它有大量的UI元素 - 可停靠的工具栏,自定义树控件,上下文菜单等.它是一个图像处理应用程序,因此主视图使用DirectX和OpenGL自我渲染.该产品大约有10年的历史,其中一个优先事项是更新它的外观和感觉.
知道微软在提供C++/MFC和.NET之间的互操作性方面做得很好,我认为以递增方式迁移代码库是有意义的.我现在正在努力的是从哪里开始.
一种方法是使用WPF删除MFC框架并尽可能多地重用C++代码.这将让我们最大限度地发挥WPF架构的优势,但这将意味着一个漫长的开发周期,直到我们再次完全正常运行.
另一种方法是用它们的WPF对应物一次替换一个MFC控件.这将允许我们以增量方式工作.我对这种方法的关注是,它意味着托管和非托管代码之间会有很多连接点,我不知道从哪里开始替换主菜单和工具栏等内容.
或者我还有其他选择吗？
任何有关此主题的信息的建议或链接将不胜感激.
更新: DavidK提出了一些很好的问题,所以我添加了这背后的动机.
1)产品的未来发展
该产品仍在积极开发中,并定期添加新功能.我认为尝试慢慢迁移到C#/ WPF会很有意义.凭借我在C#/ WPF方面的有限经验,我发现在C++/MFC中工作效率会提高.
我们用WPF获得的另一件大事就是能够利用多头系统.MFC应用程序仅限于单个顶级框架,因此很难利用多个监视器.
2)员工保留和招聘
找到愿意使用MFC的开发人员越来越难了.对于当前开发人员的职业发展而言,接触新技术也很重要.
17 *_* 26 10
重新审视这个,因为我已成功用WPF替换了我们的顶级MFC UI(主框架,窗口和工具栏).
事实证明,我们的核心绘图代码只需要交给HWND进行渲染.这使得重用大量现有C++代码库变得非常容易.
以下是我采用的方法的关键部分的快速概述:
作为旁注,我们使用了Divelements的SandDock和SandRibbon,到目前为止他们对它们非常满意.