MFC 有哪些引人注目的功能？为什么你会为一个新项目选择它？
Aaron Fischer
问问题
4797 次
14 回答
18
10 年前，MFC 是一个不错的选择。它仍然是 Win32 API 的一个很好的包装器，但不幸的是已经过时了。
Qt是一个更好的选择，它有一个很大的优势——它独立于平台。使用 MFC，您注定要使用 Windows。
于 2008-09-23T14:23:12.950 回答
11
我仍然将 MFC 用于各种应用程序。MFC 从它的早期实现中得到了一个坏名声，但它现在非常好。我发现它也比 WTL 方便得多。此外，Visual Studio 中的 GUI 工具已经设置好，可以轻松使用 MFC 快速开发 GUI、将控件映射到变量、DDX 等。
对于我打算广泛分发的桌面应用程序，我仍然使用本机 Windows 应用程序，通常在 MFC 中，因为我们还没有到您可以依赖您的客户拥有您将使用的 .NET 版本的地步安装并要求他们安装它会导致您失去销售，更不用说由于试图让您的应用程序运行而在安装 .NET 时遇到问题时的客户服务头痛。
于 2008-10-12T14:14:50.473 回答
9
MFC 的优点是它仍然比编写裸 win32 更好，并且您可以分发不需要 .Net 等 23-50Mb 运行时的本机 .exe。
现在，如果您担心这些事情，还有更好的选择：C++ Builder、WxWidgets 等。但有些地方不会考虑非 Microsoft 工具。
于 2008-09-23T14:07:15.500 回答
9
您可以改写一下这个问题，为什么要为桌面应用程序选择 C++ 而不是 C#。C++ 仍然提供速度优势，这对某些应用程序很重要（我在一家为电子交易创建软件的公司工作。速度很重要）。
如果你打算只用 C++ 开发一个针对 Windows 的桌面应用程序，那么 MFC 是最成熟的选择，网上有很多基于 MFC 的免费代码，知识渊博。
于 2008-09-23T14:08:54.483 回答
8
除了 win32 api 本身，MFC 是唯一一个在 15 年以上的 2011 年仍然活跃的主流 Windows 编程技术。早在 2001 年，每个人都说“MFC 已经死了，现在都是 Winforms”；2005 年每个人都说“MFC 已死，现在全是 XAML”；现在是 2011 年，Winforms 和 XAML 已经死了（好吧，XAML 可能并没有真正死去，但已经过了它的鼎盛时期），而 MFC 仍在更新最新的发展（功能区、Aero 扩展、Win7 API 等）。
当然，这并不能保证未来的任何事情，但是在这 15 年多的时间里，编写了很多MFC 代码，并且它将在未来十年或几十年内继续使用。它可能不是最漂亮的技术，但很容易理解（它的优点和缺点），并且不像其他炒作技术那样是一个移动目标，这意味着真正想要完成工作的人可以依赖它（更多无论如何，而不是替代品）。
（同样适用于 C++，顺便说一句）
于 2011-09-15T12:11:00.657 回答
7
这是一种可能性——想象一个需要大量内存的应用程序，比如图形程序、游戏或者一些高性能的商业应用程序。.NET 应用程序占用内存已不是什么秘密——在这种情况下，您可能需要一个精简的 MFC 应用程序作为应用程序的核心。您始终可以通过 COM 可调用包装器或直接通过 C++/CLI 加载和使用 .NET 组件、控件等。
话虽如此 - MFC 是一种痛苦。请考虑使用 WTL - 如果需要，您仍然可以调用 .NET，就像我上面提到的 MFC 一样。WTL 比 MFC 好很多 :-)
于 2008-09-23T14:18:20.950 回答
5
显然，对于基于 Windows 的手持设备（例如销售点设备）的应用程序，它仍然是一个不错的选择。在这些资源中，资源是有限的，因此内存管理之类的事情变得更加重要。
于 2008-09-23T14:08:39.693 回答
4
于 2008-09-23T14:06:45.113 回答
3
现有的 Windows API 完全基于 C。如果您想使用 C++（并且您可能应该），那么如果您希望保持原生（即不使用 .NET），那么 MFC 是合乎逻辑的选择。
MFC 只是 C API 之上的一组面向对象的类。加上不少额外的“帮助”类，可以更轻松地完成日常任务。
于 2008-09-23T14:09:39.723 回答
3
我认为不会.. MFC 会输掉
- 抽象级别
- 开发时间
- 故障排除时间
- 新开发人员的学习曲线
- 面向未来（尽管现在这是有问题的……每 3-4 年就会有新的东西出现）
- 寻找了解他们的 MFC 的好人
- 易于使用的控件
MFC 可能会偷偷溜过去的唯一地方是，如果您有一些性能非常密集的应用程序，例如您在屏幕上有需要每 10 毫秒或 1 秒重绘一次的东西。“托管”应用程序仍然无法跨越这个障碍。
MFC 是演变中的重要一步，但现在有更好的选择。
于 2008-09-23T14:31:43.103 回答
2
仅靠设计和技术优势？很抱歉是分类的，但没有。这是一个糟糕的设计，一个漏洞百出的抽象，你不得不回退到 Win32 API 编程，严重滥用 C++，并且坚定地针对过去的技术：你不会从现代的（甚至是有吸引力的！）用户体验中获得MFC 应用程序。如果您可以找到 C# 开发人员并且您没有严重的硬件限制，请使用 WinForms。
另一方面，外部因素，例如招聘能力、培训计划和第三方组件的可用性，仍然可以延长其生命周期，至少对于某些类型的应用程序而言：小而简单，针对用户相当少的特殊应用程序，最好是内部的。
于 2008-09-23T14:09:50.567 回答
2
如果您使用 C++ 开发 Windows CE 和移动应用程序，正如 Einar 已经提到的，MFC 是一个不错的选择。如果您做出此选择，那么 MFC 也将成为桌面的合理选择，因为您可以在桌面和手持设备上使用相同的代码。在这种情况下，MFC 仍然具有良好的性能/易于实现组合。就个人而言，我在这些环境中将 MFC 与 Stingray 库结合使用，它提供了非常好的界面、良好的性能并且快速且易于实现。
于 2008-10-12T14:03:02.837 回答
2
我会说速度和占用空间是 .NET 的好理由。
您可能确实会发现很难找到优秀的 MFC 程序员，但这同样是因为现代语言促进了惰性编程技术，并且大多数编程课程都倾向于他们，因为它们更容易教授。
于 2009-05-12T09:39:39.757 回答
1
我已经编写跨平台代码多年，所以当我需要编写一些东西时，我总是在它之间有一个非常薄的抽象层，系统调用几乎所有东西，除了 posix 调用。这样，您可以将其编码到 MFC 中，但如果需要，稍后可以很容易地将其转换为不同的 API。我用于一切的基本 c++ 库集通过一个小型 System 类来实现。我目前使用适用于 Windows 的 MFC，也使用适用于 Linux 的 XWindows 和本机 Mac 版本。后来当我将它移植到手持设备上时，它应该很轻松。
如果您想看一看，它是 LGPL 的，位于：
于 2008-09-23T14:23:44.323 回答