我应该为富客户端应用程序选择什么 Windows API？答案

【问题标题】：What Windows API do I choose for a rich client application?我应该为富客户端应用程序选择什么 Windows API？
【发布时间】：2008-11-12 14:31:30
【问题描述】：

我在 Mac OS X 和 Linux 上开发富客户端软件。我希望将应用程序移植到 Windows 并且不是 Microsoft 产品的用户，我对 Windows 不是很熟悉。

我所熟悉的：

在 Mac OS X 上，我可以选择 Cocoa 和 Objective C 或 Carbon 和 C/C++。在 Linux 上，我可以选择 GTK+ 和 C/C++ 或 Qt 和 C++。我更喜欢 Mac OS X 上的 Cocoa 和 Linux 上的 GTK+。 Cocoa 的 Interface Builder 和 GTK+ 的 Glade 让我的生活变得轻松。在这些操作系统中创建富客户端是有趣。

我的核心类，或 MVC 中的“模型”，是用跨平台 C++ 编写的。用户界面类，或 MVC 中的“视图和控制器”，是用每个平台的“首选”语言和 GUI API 编写的。

C++ 是我最熟悉的语言。我广泛使用 Boost 库。尤其是智能指针、线程和 asio 网络库。对于 Unicode、本地化等，我使用 International Components for Unicode (ICU)。

问题 1：与我的跨平台模型类兼容的 Windows 平台的“首选”语言和 GUI API 是什么？

问题 2：如何访问我的跨平台模型类？

例如，在 Mac OS X 上，我通过控制器类访问我的模型类。控制器类在 Objective-C++ 中实现。 Objective-C++ 是 C++ 和 Objective-C 的混合体。在 Objective-C 中查看对象与控制器对象“对话”，而在 C++ 中控制器对象与模型对象“对话”。

在 Linux 上，所有类都是用 C++ 实现的。

【问题讨论】：

标签： c++ windows visual-c++ cross-platform

【解决方案1】：

Windows 上并没有真正的“首选”语言和 API，更像是有很多选择。最明显的是直接对操作系统的原始 Win32 调用（所以实际上只是 C 调用），或者在此之上的薄抽象（例如 WTL，Windows 模板库，它是 C++），或者更厚的抽象（例如 MFC，也C++)。

Microsoft 这些天来非常努力地推动 WPF，但这是托管 .NET 世界的一部分。您可以在其中编写 C++，因此您可以移植您的应用程序，但我预计这将是一项巨大的努力。

鉴于您在 Linux 上使用 GTK+ 或 QT，显而易见的事情是考虑在 Windows 上同时使用这两者，因为两者都存在 - 这样您就可以保持 Linux 和 Windows 版本几乎相同。它们不是纯 Windows 应用程序的自然选择，因为它们最初并非来自 Windows 世界，但考虑到您的背景，它们会很有意义。您可能需要花一些时间来调整它们以使 Windows 应用程序的外观和感觉恰到好处，但这应该可以通过不需要编写全新的表示层来弥补。

【讨论】：

【解决方案2】：

Qt 在 Windows 上运行良好。而且它是独立于平台的。

【讨论】：

【解决方案3】：

如果您可以让您的 C++ 使用 Visual Studio 工具链（而不是 gcc 或 mingw）进行编译，我强烈建议您制作一个 .lib，然后将其链接到一个 C++/CLI 程序集中，在其中公开一个托管API 到您的库。

然后，您可以使用 C# 和 WinForms API 或 WPF，并拥有一个极其丰富且具有原生窗口外观的应用程序。这项工作非常简单，如果您愿意重写 GUI，它将获得最好的结果并且最容易部署。

需要注意的是，如果您需要它在可能不存在 .NET 的机器上工作——如果是这样，我会坚持使用 .NET 2.0（和 WinForms）。您还应该让安装程序检测并安装它。如果您愿意安装 .NET 3.5（如果不存在），请选择 WPF。

【讨论】：

【解决方案4】：

Windows Presentation Foundation (WPF) 是适用于 Windows 的新 Microsoft 丰富应用程序标准。你的 C++ 会移植到它，但大多数人开发 C# 是针对它的。

【讨论】：

【解决方案5】：

GTK+ 在 Windows 上运行良好。如果您已经熟悉它，那就是我会使用的。尽管性能可能与原生 Windows UI 库（如 MFC）的性能不匹配，但它已经足够好，除非您的应用程序真的依赖于 ui 性能。在所有平台上使用 GTK+ 的一个重要示例是 Pidgin。

如果没有看到一些代码，就无法真正回答您的第二个问题，但我不明白为什么它与您在其他平台上的模型-视图-控制器方法不同。

【讨论】：

对，如果您可以跨平台编写纯 Windows 代码，那么它是没有用的。当然，我更喜欢 Qt 而不是 GTK+（没有性能开销，或者 GUI 不匹配！），但是提到的问题已经喜欢 GTK+，所以保留它。

【解决方案6】：

我倾向于 Windows Presentation Foundation。我想这是微软在 Mac OS X 上对 Cocoa 的回答，因为“它旨在统一许多应用程序服务：用户界面、2D 和 3D 绘图、固定和自适应文档、高级排版、矢量图形、光栅图形、动画、数据绑定，音频和视频。”这对我来说听起来像可可:-)

我想这个实现会类似于我的 Mac OS X 实现：

模型：跨平台 C++ 类
查看：WPF 和 C#
控制器：C++/CLI 或其他东西

而在 Mac OS X 上，视图类是用 Objective-C 实现的，而控制器类是用 Objective-C++ 实现的。在 Objective-C 中查看对象与控制器对象“对话”，而在 C++ 中控制器对象与模型对象“对话”。

Windows 上的 C++/CLI 是否像 Mac OS X 上的 Objective-C++ 或 C# 类我定义在 C++/CLI 中不可访问？

从托管 .Net 语言访问 C++ 类的“正确”或“首选”方式是什么？

【讨论】：

您将 C# 视图构建到一个程序集中，并调用另一个用 C++/CLI 构建的程序集。您可以通过多种方式将跨平台 C++ 类构建到 C++/CLI 程序集中，例如将目标文件链接为静态本地库，或将源代码编译为托管代码。