我有一个具有广泛 C++ 模型的现有应用程序，我想将它连接到一个漂亮的现代 Windows 7 或 8 UI。我们应用程序的当前(古老)UI 是在早期的 Windows XP/95/98 时代使用纯 Win32 API 开发的。我们的代码目前正在通过 Visual Studio 2010 编译/链接。
Windows 上似乎有很多不同的开发 API“标准”:Win32、MFC、ATL、COM 和 .NET。在过去的 14 年里，我的工程师几乎一直在拖微软的路线:在 2001 年，它是“MFC 已死——我们必须迁移到 ATL”(我们没有)。然后“.NET 将替换 MFC”(它似乎没有)。
所以现在我们准备好转储旧的 UI 代码。使用一组可靠且高效的标准会很好，而且我们可以快速创建 UI。撇开 QT 不谈(我在 stackoverflow 上阅读了很多争论不休的优点和缺点):
1) Windows 7 和 8 的现代 UI 开发方法是使用 MFC 还是 .NET？
2) 对于 .NET 方法(假设有充分的理由选择 .NET)，我们可以将我们的 C++ 模型代码 UNMANAGED 与 .NET 应用程序一起使用吗？
3) 是否必须在 Visual Studio 2012 中进行开发，即使我们的应用最初不是为 Metro 外观设计的？
4) 是否有任何其他 Microsoft 工具包应考虑用于桌面应用程序开发？
斯蒂芬
最佳答案
看this我在 2011 年给出的答案。我认为它今天仍然有效；考虑到最近从微软转向 C++，也许更是如此。我不确定 MFC 中有多少对 win8 的额外支持，但如果您没有完全切换到 Metro(我想您不会；如果您有“产品”，则需要支持较旧的 Windows至少，什么，5年？)，这并不重要。
我还没有看到一个感觉像 C++ 一样“可靠”的 .Net/WPF 应用程序(是的，我意识到这些在技术上是正交的，但实际上，谁用 C++ 构建了 .Net UI？)。我理解人们为什么要离开 MFC；这并不是说我不了解它的消极面。 IMO，归根结底是:您对快速发展的重视程度如何？对于某些应用程序(业务线、生命周期短的产品)，上市时间和做出改变的速度比“扎实”地设计更重要。对于其他(专业工具、系统软件)而言，创建具有良好用户体验的可靠软件更为重要。我还没有看到在更“现代”的框架中执行此操作的生产软件(而不是“技术演示”)； MFC(或者我应该说'win api used through C++'，但在这方面，MFC 有足够的优势让积极因素胜过消极因素)应用程序(仍然)(通常)是最好的工具。国际海事组织。
最后要考虑的一件事是您的开发人员。如果他们已经为 MFC 编程 15 年，那么他们可能会将自己的职业生涯编程到一个角落。如果你坚持继续使用 MFC，你可能会疏远他们。您必须权衡其中的业务风险与技术考虑因素(我从您的问题中得出，您是企业主)。如果您希望私下进行，请随时与我联系以进行后续讨论。
关于.net - Windows 桌面应用程序的现代 UI 的正确方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14823493/