c – 在一个大的MFC Windows专用应用程序中使用Qt会加速开发吗？
发布时间：2020-12-16 05:03:08 所属栏目：百科 来源：网络整理
导读：我知道有很多Qt和MFC问题,但我会尝试非常具体. 我们有一个很大的(10年的开发)C MFC应用程序的利基行业.它应该永远只保留Windows和英语.但是我们需要添加一堆新的设计器绘制的GUI和GUI控件(对话框,按钮,自定义列表……). 我们可以雇用1或2个新的GUI开发人员来
|
我知道有很多Qt和MFC问题,但我会尝试非常具体.
我们有一个很大的(10年的开发)C MFC应用程序的利基行业.它应该永远只保留Windows和英语.但是我们需要添加一堆新的设计器绘制的GUI和GUI控件(对话框,按钮,自定义列表……). 我们可以雇用1或2个新的GUI开发人员来构建这些新接口,因此我们可以选择与MFC不同的技术. Qt似乎最有希望并且适合与MFC并排运行(哦,不,我们不是从头开始减少应用程序). 似乎大多数引用的Qt优势都是无关紧要的：跨平台开发,易于国际化,开源,非GUI库(我们不需要网络,并且已经实现了大部分其他功能). 但Qt也因其良好的OO设计而闻名,他们最近推出了QtQuick.我想给它一个机会,所以问题是 >在仅限商业Windows的项目中,从纯MFC迁移到MFC Qt的实质优势是什么,这值得学习Qt的麻烦,将其集成到我们的构建/部署过程中并且可能支付商业许可证？ 解决方法
可能不是.
如果gui和业务逻辑很好地分开,那么将gui逐渐移动到Qt或在Qt中实现新部件可能是有意义的 – 但我们都知道gui /逻辑将是一个可怕的混合在一起混乱 如果你正在进行重写(这将是Qt将最终作为),那么如果它是一个常规的业务类型应用程序,那么使用C#/ .net可能更容易. 如果性能至关重要且你有很多领域知识与定义良好的完全分离的c libs捆绑在一起,那么Qt前端将是值得的 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |