Windows 桌面应用程序的现代 UI 的正确方法是什么？答案

【问题标题】：What is the proper approach to modern UI for Windows Desktop Apps?Windows 桌面应用程序的现代 UI 的正确方法是什么？
【发布时间】：2013-01-27 05:23:42
【问题描述】：

我有一个现有的应用程序，它具有广泛的 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 will REPLACE 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 工具包应考虑用于桌面应用程序开发？

斯蒂芬

【问题讨论】：

标签： .net visual-studio-2010 winapi user-interface mfc

【解决方案1】：

看看我在 2011 年给出的 this 答案。我认为它今天仍然有效；考虑到最近从微软转向 C++，也许更是如此。我不确定 MFC 中有多少对 win8 的额外支持，但如果您没有完全切换到 Metro（我想您不会；如果您有“产品”，则需要支持较旧的 Windows至少，什么，5 年？），这并不重要。

我还没有看到一个 .Net/WPF 应用程序感觉像 C++ 一样“可靠”（是的，我意识到这些在技术上是正交的，但实际上，谁用 C++ 构建了 .Net UI？）。我理解人们为什么要离开 MFC；这并不是说我不了解它的消极面。 IMO，归根结底是：您对快速发展的重视程度如何？对于某些应用程序（业务线、寿命短的产品），上市时间和做出改变的速度比“扎实”地设计更重要。对于其他（专业工具、系统软件），创建具有良好用户体验的可靠软件更为重要。我还没有看到在更“现代”的框架中执行此操作的生产软件（而不是“技术演示”）； MFC（或者我应该说'win api used through C++'，但在这方面，MFC 有足够的优势让积极因素胜过消极因素）应用程序（仍然）（通常）是最好的工具。国际海事组织。

最后要考虑的是您的开发人员。如果他们已经为 MFC 编程了 15 年，那么他们可能会将自己的职业生涯编程到一个角落。如果你坚持继续使用 MFC，你可能会疏远他们。您必须权衡其中的业务风险与技术考虑因素（我从您的问题中得出，您是企业主）。如果您希望私下进行后续讨论，请随时与我联系。

【讨论】：

我认为有很多 WPF 应用程序（或至少大量使用 WPF）是“可靠的”，包括 Visual Studio。
@Roel -- 最后 -- 关于开发人员的主题：我是一名企业主，但我也编程 (C++)，并吸取了让工程师做出战略性业务决策的惨痛教训：更多工程师通常会希望使用新的、不同的和/或令人兴奋的技术——这是人的本性，他们必须专注于自己的职业，而不是如何在未来 10 年最好地维护代码......跨度>
@Reed Copsey - 我不想说出名字，但我认为 Visual Studio 是一个非常不可靠的软件示例。如果我们提供那种质量以及硬件/操作系统升级速度如此之快，我的客户会犹豫不决。想象一下，MS 拥有所有人、金钱和时间来充分利用 WPF（以及在下一栋大楼中构建它的人），而 VS 仍然是他们能做的最好的吗？那么我们这些凡人又有什么机会呢？但同样，这是一个观众是谁的问题，我猜 MS 决定开发人员可以接受它。
@Roel 我认为在 C# .NET（WinForms 而非 WFP）中构建的可靠原生 UI 并在需要时调用原生 C++ 库没有任何问题。大多数 .NET WinForms UI 组件使用底层的原生 Win32 控件和窗口，并使用与 WPF 和 MFC 相同的视觉样式和效果进行渲染（某些 MFC UI 元素是非原生的且丑陋的）。
@Roel Media Player Classic Home Cinema 就是一个很好的例子。

【解决方案2】：

您可以采用任何一种方法。但是，.NET 在用户界面设计中更为常见，如果您需要灵活的用户界面，它具有许多优势（在更快的开发方面）。
是的。 C++/CLI 可以很好地将本机代码与 .NET 用户界面联系起来。
没有。您可以在 VS2010 中执行此操作。话虽如此，VS 2012 确实有很多优势，尤其是在使用 C++ 时。升级可能是有益的。
我会看WPF。新的 Windows 8 用户界面可能很有趣，但可能难以与您以前的代码库一起使用。此外，它不适用于较旧的操作系统。根据我的经验，WPF 是目前改进的最佳选项（.NET 4.5 中有许多改进），它支持将现有代码库与新的用户界面技术混合。

【讨论】：

.NET 通常会与 Windows 窗体结合使用吗？如果是这样，底层代码是 C#，对吧？
@SMGreenfield 您可以将 .NET 与 WinForms 一起使用——不过，正如我所说，今天我会使用 WPF。您通常会在 C#（或 VB，但如果您是 C++ 开发人员，C# 会更舒服）中编写“视图逻辑”，然后在下面与您的 C++ 逻辑集成。这是 Visual Studio 自 VS2010 以来使用的方法，顺便说一句（它是 WPF 前端，下面有很多遗留的本机代码）

【解决方案3】：

一个非常容易说的解决方案是将整个 C++ 代码移植到 .NET 的 C# 或 C++/CLI，然后将其与 WPF 接口。这可能很复杂，但是，您可以享受完全在 .NET 中轻松编码的乐趣（最好使用 3.5 SP1 和 Visual Studio 2010）。

您还可以将现有代码连接到 .NET，以通过 COM 互操作使用 WPF。 COM Interop 本质上将 .NET 组件注册为系统中的 COM 组件。当它被调用时，CLR 执行代码执行和编组以供您的程序调用（更多信息 - msdn.microsoft.com/en-us/library/zsfww439(v=vs.80).aspx）。

最后一种方法是转储 MFC 并直接调用 Windows (Win32) API。 Windows API 比其他方法更容易在您的代码中使用。在现代 Windows API 中，GDI+（图形设备接口）在 DirectX（DWM 和 DXGI）之上实现，可以通过 COM 轻松扩展，是 WPF 和现代 UI 的一种可行的替代方案。

【讨论】：

【解决方案4】：

没有人应该创建基于 MFC 和 Win32 的新项目。 Windows 现代 UI 和统一 API 是未来。我不认为 .Net 是每个应用程序的答案，尤其是对于具有大量 C++ 本机代码的项目。我们知道微软正在开发统一的 API。我希望这就是这个问题的答案。

【讨论】：

“我们知道微软正在开发统一的 API。” -> 那么为什么不等待统一的 API 呢？