我的同事正在使用Visual Studio 2002并使用C ++ MFC。我正在用C＃开发。
以前没有任何问题，但现在质疑我们的客户是否真的应该在不同的环境中发展。我的同事们（当然）认为我应该转向C ++ MFC。我认为他们可以使用.NET而不是MFC。
有没有理由学习MFC？感觉有点过时了，还是我错了？与MFC相比，针对.NET和.NET的论点是什么？
修改
我们正在为核工业开发过程系统和辅助应用程序。主要应用程序是模拟旧计算机系统并使用C ++ / MFC的模拟器。它是非常关键的时间，也许它应该仍然是原生C ++中的核心。但是模拟器和所有周围应用程序的GUI并不是特别关键。
您是否应该更换现有的MFC应用程序？
答案 0 :(得分：82)
我已经在很长一段时间内广泛使用了MFC和Windows Forms。我来自视频游戏行业，因此多年来不得不编写许多桌面应用程序，而在.net之前，MFC非常有用。甚至在此之前我就是用纯Win32编写工具。
MFC肯定有它的怪癖，但总的来说它让生活变得更轻松。将OpenGL和Direct3D集成到自定义视图中非常容易，一旦掌握了它，编写自定义控件就是小菜一碟。最重要的是，我可以用纯C ++编写代码，这恰好是我选择的语言。另外，我发现MFC非常高效和活泼。
渐渐地，MFC开始获得外部控制库支持，特别是对接/工具库库，所以我的工具，如3D模型查看器和关卡编辑器，看起来都很漂亮。
我编写的大多数应用程序都以编程方式创建了UI，因此对话框/窗口布局工具足以满足我的需求。
MFC 9也非常酷，尤其是Microsoft作为Feature Pack的一部分发布的Ribbon控件/扩展库。所以老狗还有生命，当然！ ：）
当.net 1.0问世时，我发现转换相当容易，因为它支持托管C ++。它并不漂亮，但为.net框架提供了一个相对简单的入口。但是当我开始编写需要Windows Forms Designer的工具时，我的转折点出现在.net 2.0的时候。我决定重新开始学习C＃，我喜欢它 - 尽管我永远不会习惯在没有delete（）的情况下使用new（）;）。然后我开始编写用户控件，发现整个体验非常好而且直截了当。 .net框架非常庞大，得到了很好的支持，通常我发现C＃/ .net中的所有内容都更容易。另外，编译很快，并且在Visual Studio中重构的能力非常棒。
c＃/ .net的优点在于它不会限制您只使用托管代码编写。如果性能是一个问题，或者您需要在平台之间共享代码，您仍然可以使用非托管代码。例如，我的数学库是用C / C ++编写的，我将它放入一个库中，使C＃能够包装/使用相同的代码，尽管这只是暂时的。我要及时将这些库移植到C＃，所以一切都是纯粹的.net。
我想提到的最后一次经历是，过去几个月我一直在远离控制台游戏编程，并花时间编程InterWeb。我一直在使用Microsoft堆栈，在ASP.net/C#中编程，我不得不说它非常好，所有C＃的知识都可以直接应用。唯一的学习曲线是ASP.net，而不是语言和支持库。随着.net 3.5（LINQ很好）的到来，.net框架中的C＃生活很可爱。
无论如何，我不想把它变成我生活中的故事，但我只想简单介绍一下那些已经了解了你所提出的所有技术的人。我还想提一下，尝试不同的语言/框架对你有好处。我已经为iPhone编写了一年的编码，并且已经发展到非常喜欢Objective-C。这都是编程，而且一切都很好。
关于MFC / .net，两者都有它们的优点和缺点，我真的不介意MFC，但就前进而言，我可能会坚持使用C＃/ .net，但请，拜托，请理解它是如何工作的。我要说的唯一有说服力的事情就是要了解.net中的记忆是如何工作的，即使“这一切都是为你照顾的”;）
你对C / C ++的了解应该完全独立于你是否使用MFC，它仍然是一种关键语言（特别是在基于控制台的视频游戏编程中），但对于Windows上的桌面应用程序编程，它越来越难了反对.net。它快速，简单，具有出色的工具支持，优秀的第三方库，庞大的社区，现在是跨平台（Mono），可以让您在所有当前/新兴的Microsoft技术之间移动（ASP.net，WPF，Silverlight，WCF）等）。
尽管如此，我仍然将Visual Studio设置为C ++环境。有些习惯永远不会死;）
答案 1 :(得分：40)
MFC和.NET处于几乎相反的极端，每个都以自己的方式彻底蹩脚。
使用MFC大致是生活在第二次世界大战剩余建筑的腐朽残骸中。没有任何迹象可以警告危险区域，并且可能没有立即明白在哪里可以找到自来水，电力或厕所 - 即使所有这些都在那里，如果你知道如何找到它们。像任何腐朽的建筑一样，墙壁上有很多洞，所以你可以随时随地离开。同样地，从外部世界拖入东西也很容易，尽管你可以通过“拖动”来实现这一目标。
使用.NET就像生活在 The Truman Show 一样。它符合一个人对现实生活应该的想法。在其边界内，生活似乎是乌托邦式的。然而，最后，它只不过是一个令人愉快的监狱牢房，而且它所描绘的生活都不是真实的。你与外界的所有互动都受到导演的一时兴起，导演的目的主要是提高他自己的收视率;只有在影响他的情况下才会考虑你的福利。
与大多数监狱不同，.NET确实有一个标记清晰的逃生路线（标有“P / Invoke”）。然而，就像从任何好监狱逃生的路线一样，它是一英里长的污水管。大多数居民都知道它的存在，但几乎唯一去过那里的人是青少年证明他们的男子气概。实际使用的少数人只是在极其必要的情况下这样做。我们这些经常发现必要的人已经意识到最好只留在外面而不是回去。
编辑：因为有些人想要在每个人的背面使用圆圈和箭头以及一个段落作为法庭证据：MFC的优点和缺点在于它主要是围绕API的相当薄的包装器。这是一个弱点，因为它的覆盖范围内存在相当多的漏洞，并且因为它在API本身不能很好地融合在一起的地方“平滑”相对较少。例如，如果某些东西是使用COM实现的，那么它通常会直接显示在使用它的代码中。这是一种优势，因为将MFC扩展到处理默认情况下的区域非常容易，并且只需绕过它并在需要时直接使用API。它也经常被更新，因此虽然它目前可以产生合理的“现代”外观应用程序，但情况并非总是如此。鉴于其历史，很难预测它会继续如此。
.NET的优点和缺点在于它是一个围绕API的“更厚”的包装器。它在API中的“平滑”差异方面做得更多，因此（例如）在COM中实现的部件与直接C函数调用实现的部件看起来/行为明显不同。从.NET内部，差异消失了。 .NET是（目前）微软最受欢迎的技术，因此它更加定期更新，并且可以更好地确保您的UI遵循最新的指南。我的猜测是，它比MFC更有可能在一段时间内继续这样做。
.NET的弱点是绕过或扩展要困难得多。基本上，你通往外界的唯一途径是通过P / Invoke。即使是小型短途旅行，它也是丑陋和痛苦的。试图经常使用它或任何接近主要延伸的东西都是受虐狂的练习。
如果（几乎）您编写的所有内容都适合.NET支持，那么这是明确的选择。只要你留在它的边界内，它就会更清洁，更顺畅。
如果您编写的代码经常需要超出框架支持的范围，MFC可能会更好地为您工作。使用.NET，.NET模型适用于整个程序。使用MFC，编写使用MFC作为UI的程序相对容易，并且可以根据MFC不支持的任何其他方式执行操作。
答案 2 :(得分：25)
我认为知道C ++是有价值的，因为语言将会存在很长时间。你永远不知道何时需要用C ++进行编程，而在今天的就业市场中，拥有更多语言只会增强你的简历。
关于MFC，我正在尽力摆脱它。计算标准已经过时了（我认为接近20年），但微软仍然认为通过新版本和功能包支持它的价值。从这个角度来看，我怀疑MFC会很快消失。但这并不意味着我想用它编程。一个人可以在C＃中编程的流动性和易用性使得MFC / C ++的每一天都能脱离MFC / C ++。线程，套接字，字符串操作等 - 所有这些事情在C＃中比在C ++中更容易实现。此外，C＃/。NET是微软的主要技术重点，在职业发展方面，我宁愿在MFC背后也是如此。
答案 3 :(得分：3)
这不是一个与另一个。从1.1版开始，Windows Forms支持由本机客户端（如IE或MFC对话框）托管。 MFC 8.0将必要的托管代码包装在Windows窗体支持类中，因此您无需编写自己的托管代码。根据您当前项目的要求选择合适的库。
然而，MFC不仅仅是它的GDI包装类。曾经有一次它被设计为底层Win32 API的OOP替代品，就像今天的.Net一样。但是，MFC没有阻止Win32 API的发展，现在我可以说win32 API来自MFC可以支持的内容。在过去十年中，API的数量增加了数十倍。
另一方面，Windows Forms只是Windows GDI系统的替代品。其余的.NET Framework库旨在取代Win32的其余部分，例如用于DirectX的WPF和XNA以及用于SAPI的System.Speech。但是，我可以看到win32 API在.Net可以跟上的情况下成长，而不会在几年内显着增加下载量。因此，Windows Forms无法完成MFC可以执行的所有操作，它旨在使基于GDI +的RAD更容易，并且可能包含MFC无法执行的操作。然而，随着微软重新关注WPF，基于GDI +的Windows窗体正在走下坡路，而MFC则根据消费者的要求重新启动。如果您正在为将来的应用程序进行设计，您可能需要考虑这一点。
答案 4 :(得分：3)
您希望解决的问题是什么？假设您同样了解C ++ / MFC和C＃/ .NET。哪个工具集可以让您更好地构建和维护？ （更好是主观的，但又取决于你的目标）
除非我使用.NET中没有的本机API做很多工作，否则我将使用.NET。 C ++是一种很好的语言，没有什么可以阻止你在托管C ++中进行编码，从而保持.NET框架和内存管理。
相比之下，我的观察结果是，与.NET Windows表单相比，MFC框架非常具有笨拙性和笨重性。
答案 5 :(得分：3)
MFC提供的一个很好的功能是Document / View框架（单个文档或多个文档），它们在.NET中还没有等价。当您需要创建类似Microsoft Word的应用程序时，此功能非常有用且方便。它有助于将数据模型与要向用户表示的视图分开。我认为一旦实现此功能，大多数人都会跳到.NET端。 （微软正在研究这个问题，或者至少有计划对此进行研究吗？）
答案 6 :(得分：3)
哦，天哪。我知道我参加这个聚会太迟了，但是作为一个用C和纯Win32编写的人，然后是他在C ++ / VC / MFC中大部分职业的人，用C＃和WPF编写都是很痛苦的！我知道我是新手，但是我强迫自己用C＃编写这个小应用程序，因为我想对C＃/。NET和WPF更加满意。虽然我能够轻松地将UI做成光滑的黑色是一件很不错的事，但是我定义菜单所花的时间却是在MFC中创建菜单资源，添加菜单项然后向其中添加事件处理程序的时间。他们与轻松！这是苦力。我喜欢C＃作为一种语言，但是如果我可以像使用MFC / Windows在资源编辑器中那样定义所有内容，并像WPF中一样添加爵士元素，则我会更喜欢这种语言。
答案 7 :(得分：2)
这个选择有很多优点/缺点。 MFC是古老的支持者，它已经存在了很长时间并且确实显示了它的年龄。另一方面，它仍然得到相当好的支持，MS不断更新它以保持最新状态。
.Net框架有更好的支持，因为它有一个更大的团队支持它，并被视为构建Windows新部分的东西。
另一方面，MFC是Windows生态系统的重要组成部分。如果你正在平台上进行编程，那么至少要了解MFC的工作知识以及如何最终支持MFC应用程序（并且不用担心，有一天你会这样做）将是值得的。有一个良好的基础，从哪里开始。
答案 8 :(得分：2)
我在一年多前从C ++ / MFC过渡到C＃/ WinForms（我知道，已经很晚了）。
除了语言差异之外，从MFC过渡到WinForms比从另一个方面转移要容易得多。我认为，如果您打算有效地维护遗留应用程序，那么了解MFC绝对有价值。但是：
我是否会从头开始学习MFC（现有技术）？不，可能不是。
我会在MFC中编写新的应用程序吗？不，可能不是。
.NET的支持，灵活性和易用性远远超过了MFC的优势。对于它是什么，MFC是一流的，我很高兴有机会与它合作 - 它教会了我很多。不过，最终它正在逐渐消失。
答案 9 :(得分：1)
非托管代码不一定执行得更快，它取决于编写的代码和编写代码的代码。我已经阅读了一些复杂的基准测试报告（源代码，代码项目），以及C＃在某些方面击败C ++，C ++在其他方面获胜。这取决于你的领域：我为Flight Simulators编写软件，因此需要一个非托管环境。如果您正在制作GUI应用程序，C＃可能是更好的选择。对于低杠杆套接字编程，C ++可能会返回更好的结果。我注意到在正常操作中C ++和C＃之间没有明显的速度差异，但我很喜欢C ++的本机可移植性和C＃，因为它很容易。
答案 10 :(得分：-3)
.NET使用托管代码。 MFC使用非托管代码。我已经读过非托管代码比托管代码执行得更快。因此，如果您正在开发软实时代码，则可能需要使用非托管代码。