MFC的引人注目的功能是什么？为什么要为新项目选择它？

解决方案

快速浏览新的MFC功能

我听说他们有一个新的功能区控件。如果我们喜欢这种复杂性。这是一个新生成的应用程序的屏幕截图：

http://blogs.msdn.com/blogfiles/vcblog/WindowsLiveWriter/QuickTourOfNewMFCFunctionality_C777/Wizard%20Generated%20with%20accelerator%20tips_2.jpg

确实，这只是一个小部件更新。那么，我们需要更多的小部件吗？

MFC的优点是，它比编码裸Win32更好，并且我们可以分发不需要23-50Mb运行时(如.Net)的本机.exe。

现在，如果我们担心这些问题，那么还有更好的选择：C ++ Builder，WxWidgets等。但是有些地方不会考虑使用非Microsoft工具。

显然，对于基于Windows的手持设备(例如销售点设备)的应用程序，它仍然是一个不错的选择。在这些资源中，资源是有限的，因此诸如内存管理之类的事情变得更加重要。

我们可能会重新提出这个问题，为什么我们要为台式机应用程序选择C ++而不是C ++。 C ++仍然提供对某些应用程序重要的速度优势(我在一家创建电子交易软件的公司工作。速度非常重要)。

如果我们打算开发仅适用于C ++的Windows的桌面应用程序，那么MFC是最成熟的选择，它在互联网上提供了大量基于MFC的免费代码，并且拥有很多知识。

现有的Windows API完全基于C。如果我们想使用C ++(也许应该)，那么如果我们希望保持本机状态(即不使用.NET)，则MFC是合理的选择。

MFC只是C API顶部的一组面向对象的类。加上许多其他的"帮助程序"类，这些类使执行日常任务变得更加容易。

仅凭设计和技术优势？很抱歉是绝对的，但没有。这是一个糟糕的设计，一个巨大的泄漏抽象，我们必须依靠Win32 API编程，严重滥用C ++，并且坚决针对昨天的技术：我们将无法获得现代(甚至是吸引人的！)用户体验。 MFC应用程序。如果可以聘请Cdevelopers并且我们没有严格的硬件限制，请使用WinForms。

另一方面，外部因素(例如，聘用人员的能力，培训计划和第三方组件)仍然可以延长其寿命，至少对于某些类型的应用程序来说是这样：小巧，简单，针对用户较少的特殊应用，最好在公司内部。

有一种可能，想象一个需要大量内存的应用程序，例如图形程序，游戏或者某些高性能的业务应用程序。在这种情况下，.NET应用程序占用内存并不是什么秘密，我们可能需要精益的MFC应用程序作为应用程序的核心。我们始终可以通过COM可调用包装器或者直接通过C ++ / CLI加载和使用.NET组件，控件等。

MFC所说的一切都是痛苦的。考虑使用WTL，但仍可以根据需要调用.NET，就像我上面提到的MFC一样。 WTL比MFC好很多:-)

MFC在10年前是个不错的选择。它仍然是Win32 API的一个很好的包装，但是不幸的是已经过时了。

奇趣的QT是更好的选择，它的一大优势是平台无关。使用MFC，我们注定要使用Windows。

我已经编写了跨平台代码多年，因此，当我需要编写某些东西时，除posix调用之外，几乎所有内容都与系统调用之间存在非常薄的抽象层。这样，我们就可以将其编码到MFC中，但是如果需要的话，以后可以很容易地将其转换为其他API。我用于所有工作的基础c ++库集都是通过一个小型System类来实现的。我目前使用Windows的MFC来使用它，也使用Linux的XWindows以及本机Mac版本来使用它。后来，当我将其移植到手持设备上时，它应该会很轻松。

如果我们想窥视一下，那是LGPL专用的，地址为：

http://code.google.com/p/kgui/

我认为不是。MFC会输掉

• 抽象级别
• 开发时间
• 故障排除时间
• 新开发者的学习曲线
• 面向未来的证明(尽管现在是有问题的..每隔3-4年就会出现一些新情况)
• 寻找认识他们的MFC的好人
• 易于使用的控件

MFC可能会溜走的唯一地方是，如果我们有一些性能非常密集的应用程序，例如屏幕上的东西需要每10毫秒或者1秒重新绘制一次。 "托管"应用仍然无法克服这一障碍。

MFC是发展的重要一步，但是现在有更好的选择可用。

如Einar所述，如果我们正在用C ++开发Windows CE和移动应用程序，则MFC是一个不错的选择。如果我们做出选择，那么MFC也将成为台式机的合理选择，因为我们可以在台式机和手持设备上使用相同的代码。在这种情况下，MFC仍然具有良好的性能/易于实现组合。就个人而言，我在这些环境中将MFC与Stingray库结合使用，从而提供了非常好的界面，良好的性能并且易于实现。

我仍然将MFC用于所有类型的应用程序。 MFC的早期实现方式说不过去，但现在非常出色。我发现它也比WTL方便得多。加上已经在Visual Studio中设置了GUI工具，可以轻松地使用MFC快速开发GUI，将控件映射到变量，DDX等。

对于我打算广泛分发的桌面应用程序，我仍然会使用本机Windows应用程序(通常在MFC中)，因为我们仍然无法依靠客户获得将要使用的.NET版本。安装并要求他们安装它会导致我们损失销售，更不用说客户服务头痛，因为他们试图尝试运行应用程序时遇到了安装.NET的问题。

我想说，速度和占用空间是.NET的充分理由。

确实，我们会发现很难找到优秀的MFC程序员，但这同样是因为现代语言提倡懒惰的编程技术，并且大多数编程课程都更易于学习，因此倾向于使用它们。