在一个只使用MFC Windows的大型应用程序中使用Qt会加快开发速度吗？

Question

我知道有很多Qt和MFC的问题，但我会尽力做到非常具体。

我们有一个大的(10年的发展) C++燃料电池应用于利基产业。它应该永远只保留Windows和英语。但是我们需要添加一堆新的设计器绘制的GUI和GUI控件(对话框、按钮、自定义列表，.)。

我们可以雇佣一两个新的GUI开发人员来构建这些新的界面，所以我们可以选择与MFC不同的技术。

Qt似乎是最有希望的，并且适合与MFC并行运行(哦，不，我们不会从头开始重新开发这个应用程序)。

似乎大多数被引用的Qt优势都与此无关:跨平台开发、容易国际化、开放源码、非GUI库(我们不需要联网，并且已经实现了大多数其他特性)。

但Qt也以其良好的OO设计而闻名，他们最近推出了QtQuick。我想给它一个机会，所以问题是

• 在一个只使用的商业项目中，从纯MFC迁移到MFC+Qt有什么实质优势，这值得学习Qt，将其集成到我们的构建/部署过程中，也许还需要支付商业许可证？
• 特别是，如果我们在Qt中构建新的GUI并通过QWinWidget将它们合并到应用程序中，它会加速开发吗？

Answer 1

可能不会。

如果gui和业务逻辑很好地分开，那么将gui逐步转移到Qt或在Qt中实现新的部分可能是有意义的，但我们都知道gui/逻辑将是一个可怕的混合在一起的混乱。

如果您正在进行重写(这是Qt的最终结果)，那么如果它是一个常规业务类型的应用程序，那么使用C#/..net可能更容易一些。

如果性能是关键的，并且您有很多域知识绑定在定义良好、分离良好的c++库中，那么Qt前端将是值得的。

Answer 2

基本上没有回答一个问题，但可能会有帮助。我认为用较新的工具做GUI的另一种方法是使用ActiveX和COM。我相信您可以很容易地在您的MFC应用程序中使用ActiveX组件。此外，有许多方法来创建这样的控件。我曾使用Delphi来完成在.NET WinForms应用程序中成功使用的控件，但据我所知，这些控件可以在.NET环境中创建，而且不费太大力气。