http://bbs.csdn.net/topics/391817496
完全没想到10多年后还有人纠结要不要学MFC，我花点时间给新人们一个总结。
第1种观点 学习完MFC，你会更理解编程的思想，再学别的语言就更快了。
话说小白要去美国学技术，大黑劝他说：“你为什么不先到朝鲜，然后从朝鲜再飞到美国”，小白茫然不解。大黑接着说“你想你先到朝鲜再去美国，不是比从中国直接去美国近吗？”小白恍然大悟，“并且你到了朝鲜，那里有金太阳的照耀，你会更明白技术的思想。后面再学任何技术都很快。”于是小白去了朝鲜，然后他才知道原来朝鲜才是最好的地方，他给大黑打了长途电话，大黑问：“你感觉怎么样？”小白激动的说“我在学习用小刀刻芯片呢，听说美国都是动动按钮，学不到真正的东西。”
有的人要说“你看我就是先学了三年MFC，再学别的语言一样很快”，是，你要是先学三年JAVA或C#，再学别的语言会更快。你学三年MFC不是去跟零相比，是跟学三年其它语言比。在经济学上这叫机会成本，曼昆“你在面临选择的时候，要考虑的是机会成本”。
第2种观点 MFC接近于系统的底层，适合系统级的开发，学习他更能理解操作系统。
MFC能直接调用C，别的语言不能直接调用C吗？那.Net Interop是干什么的？醒醒吧！别说C，连MFC的DLL都有办法调用呢。
你真的觉得学习CDocument, CView, CWnd, CFrameWnd。。。这些绕来绕去的东西会更理解Windows？要更深的理解Windows要学习Win32编程，学习Windows核心编程，不是那个MFC，再说WinRT比Win32要好用的多。
第3种观点 MFC开发的程序运行效率高
MFC主要用来开发客户端程序，这里应该是跟C#对比，C#以前是托管程序，现在C#开发的Windows程序已经能编译成native了，运行效率提高了1.6倍左右吧，MFC是沉舟侧畔千帆过，船舱里的人还以为在乘风破浪。对了，visual studio的界面是用什么开发的呢？
还有一些观点，像什么刀呀剑呀，还有什么“你MFC用不好，也用不好C#”，就不一一列举了。很多时候辩证法就是粗看去很有哲理，实际毫无实际的指导意义。
为什么还有一些人推荐MFC？
话清末要废除科举制度，进京赶考的举子跪在外面绝食抗议，朝堂之上还有大臣坚持科举有多么好。是啊，你想这些老秀才学习四书五经学了半辈子，一下子又不考了，多少年的心血白费了。考物理，化学，代数，几乎给他们判了死刑。对于一个多年学习MFC，又不会别的语言的人，基本上也是深度套牢了。我记得冰河世纪里有一只老刺猬，洪水要来了，他躲在洞里不走“I was born in this hole and I'll die in this hole.”坚持是一种品质，顽固和守旧却是另外一回事了。这对于新手来说是一个很好的教训。
为什么还有很多刚毕业的大学生学习MFC？
因为他们的老师是上面所说的那些人。
MFC总有适合用的地方吧？
有，适合用在上世纪90年代开发Windows客户端程序。
MFC现在一点用都没有了吗？
不是，历史上遗留下来一些MFC的源代码需要维护。可能偶尔会用几个开源项目，就像弹药不够的时候偶尔也拼一下刺刀。
MFC应该跟什么语言比较？
Borland C++，VB6，Delphi，PB等。
什么人还需要关心一下MFC？
IT历史学家需要大写特写MFC曾经短暂的辉煌，考古学家需要考证这块化石的时候。
http://bbs.csdn.net/topics/391817496#post-400327680
MFC就是微软一个框架类 跟QT、WTL基本就是同类产品
唯一区别就是MFC没有维护，没有创新了，而QT挂着跨平台的称号（也就是外层统一API，如果linux则调用linux的API，微软的就调用微软的系统API）
小白也好，大神也好。认为当前项目有必要使用MFC就用
你想让小白直接用系统API写代码，也可以啊，一个main函数，然后创建窗口，创建按钮等等等
我不知道你喷MFC有什么意义？你喷MFC，跟你喷QT有区别？QT我可以说，他就是另一个MFC，唯一就是跨平台
如果微软再升级一次MFC，封装一下linux的API跟windows的API，秒你QT分分钟
我入门的时候，就是看的MFC，因为MFC简单易懂，我不需要关心系统API，我只需要调用MFC的API就能实现我的功能
通过MFC，再去玩WTL、纯API开发，就简单多了，这是我的经历，我不知道其他人是什么情况。
但是你喷MFC是毫无意义的事情。。。
我的题目是新手彻底放弃没落的MFC，并没有说MFC彻底没落，更不是说MFC一点用也没有。你说的很清楚，MFC毕竟是15年前的设计，它的定位就是局限在开发Windows 95内核上的客户端。既不能用于手机开发，又不能用于物联网。当然，还有应用服务器，Web服务器，数据库服务器就更不用说了。使用者越来越少不是很明显的趋势吗？所以我建议新手放弃MFC是没有问题的。
编程语言，框架，工具等之研发团队就像武器之军队，原子弹的出现并没有淘汰掉冲锋枪，甚至古老的匕首也存在着不可替代的作用，这是武器的生存空间问题。如果从整个作战系统的全局来考虑每一类武器的生存空间，重骑兵，投石车，被淘汰也就在情理之中了。MFC就像投石车，即使发明它的企业也早就不做任何改进了，而远程投射系已经经历了大炮，火箭炮，进而向弹道导弹的方向推进，它未来的生存空间在哪里？
某项技术好不好我这种菜鸟没发言权，但C#之类的东西运行慢是真的，能感觉得到，而且还得一大堆库的支持，烦得很。
QT也慢，不知道怎么回事。
MFC胜在简单、通用、稳定，它还是有自己的市场的，一些偏硬件的公司通常用它做上位机软件（当然也有选择用C#的），这些软件完全不需要花哨的界面，只关注功能的实现，MFC是非常好的选择，需要的维护人员也少。
无论MFC也好，WTL也好，WPF也好，QT也好，都是工具，各有自己的特点，谁熟练就用谁，不过，论学习成本，我还是觉得MFC是最容易掌握的
Visual C++前面的那个Visual指的是可视化界面编程，是本质特点，而MFC就是界面编程的基础类库。界面编程就是MFC编程的主战场，逃离了界面战场它什么都不是。MFC的简单易用只是相对于Windows API的，因为它是对Windows API的封装，它的快只是相当于在没有飞机之前的时代，蒙古的骑兵的那种快。
你在这展示的恰恰是MFC的局限性，当然这首先是GDI的局限性，花哨的界面都是靠贴图，切换图片。图片都是静态的，是死的，如果你用图片表示一个电池，还要设计多个图片表示电池的不同状态，比如说电量报警的情况。如果还要根据电量的数值来绘制电量的饱满程度，就只能用自定义控件了。界面设计师只能用PS来设计，设计出来程序员还不一定能开发出来。
另外，15年的发展，显卡已经从一个黄脸婆发展成一个亭亭玉立，芳龄二八的美少女了，而MFC从一个壮小伙子逐渐发展成82高龄的老翁。无论她有多少炫丽夺目的功能和性能，他已经再也驱动不了了，只能多买一此衣服让切换。如果说他们仍然深爱着对方，不得不说是思想层面的事了，哦，“思想”真是个好词，有什么事说不通，就可以说成是“思想“上的。
从未放弃过MFC
现在掌握两种语言：C#与MFC
个人认为两种各有特色，对同一个工程：
C#:开发周期短，UI及各类控件五花八门，简单易用
MFC:开发周期长，UI不好建立（虽然有bcg之类的），但效率比较高
目前没有放弃的原因，是现阶段主要进行视觉类程序开发，工业级方面的应用，效率非常重要，公司的一
个产品，进行视觉检测，C#执行120ms，C++下只要60-70ms
另外还是习惯MFC下的代码编写，C#里面写个跨线程，更新用户UI之类的，用委托，麻烦的要死
所谓MFC思想（一）
好多人都强调学MFC关键是它的思想，好，我就把它从思想的火锅里捞上来，用手术刀剖开让大家看看它混乱的思想。从面向对象来看，界面类的内聚性很差，ID_，IDC_保存在Resource.h里，界面元素，布局等都保存在rc文件里，一个界面类的代码不能从根本上独立，这样所有的界面类自然而然的产生了耦合，这直接导致编码工作难以单元化，而这是根本性缺陷，必然给所有工作增加不必要的复杂度。比如集成工作要手工处理Resource.h，RC文件等，当然还有不同类库之间宏定义，WM_的冲突等等。比如配置管理工作，配置项识别就纠结不清，必然导致分支与合并额外的重复手工劳动，而手工劳动最容易引进新的错误。单元测试就更不用说了，MFC基本上处于软件开发的手工作坊阶段。这就是MFC过人的思想？不过，从另一个角度，MFC作为反面的教材有值得深思的地方。
请问学会MFC都要学些什么呢？DOC-VIEW，OLE，UI线程，泵，钩，还是堆，栈内存分配与回收的机制？还是那些各种各样的CHAR，还是__cdecl， __stdcall，PASCAL等等，或者编译，链接的各种各样的参数？
继续讲故事，
MFC新婚之夜
红烛高照，MFC美女偎依在VC程序员的怀里，娇羞不语，只见她身上只剩下最后一件罗衫了，上面印着两个斗大的字“思想”，她用手轻轻按住新郎的手，“爱到这一层就不能再往下了”，新郎不解“为什么呢?”他的目光似乎已经穿透罗衫，MFC压低了声音：“除非你发誓，一辈子只爱我一个，不能爱其它任何女人。“新郎略一思索，他也没见过其它美女呢，“我发誓，一辈子只爱你一个。”印着”思想“的那块布慢慢滑落，新郎顿时惊呆了，MFC分明就是一个透明人，五脏六腑一古脑的展现在新郎面前，扑哧扑哧跳动的心脏，缓缓蠕动的肠子。MFC急了，”我就说你别往下看了，你就不听，你还爱我吗？“VC程序员心想，又没见过别的美女，可能别的美女也都是这样的。赶紧说：”爱，爱，爱。“MFC有点诧异：“为什么？”新郎来不及多想，脱口而出：”这样我能学到更多的东西。“
过了几年，丈母娘来了，沉思良久难以启齿，“这么说吧，当年我年轻的时候，邻居家有一个好闺女，我气不过跟别人家呕气，于是就生了MFC，没想到早产，天生有一些缺陷”。“什么？”VC程序员瞪大了眼睛“您不是一直声称，MFC是天下最好的美女吗？”丈母娘一见姑爷急了，马上说：“对对对，以前这么说没有错。不过我这几年又生了一个闺女，这一次才是最完美的。我现在想把这个闺女嫁给你，把MFC换回去。“
VC程序员脸一下涨得通红：“给我什么也不换，我只要MFC。”
“免费嫁给你也不要吗？不用买车买房，也不用聘礼。”
”我不希罕，我已经答应MFC，要爱她一辈子。”
丈母娘有点无奈了，”我不知道你跟MFC发展到哪一步了，她的很多内部细节在不该暴露的时候都暴露了。“
VC程序员显得很得意，”哈哈，我就喜欢她这样，这样我能学到更多的东西“。时间真是个魔鬼，几年的时间VC程序员已经完全习惯了MFC这种特殊的构造。
丈母娘叹了口气，MFC这个闰女害得她受了不少骂，没想到还有这么爱MFC的，难道爱一个人真的就会爱她的全部，包括缺点？不过这种爱法太匪夷所思了，会不会是因为从来没见过别的Girl，误以为自己一直深爱着MFC呢？"你是不是从来没见过别的Girl呀？"
“Girl？”VC程序员显得很不屑，"是CGirl好吗，有了MFC，我为什么还要去看别的CGirl？”
丈母娘显然有些语无伦次了，”要不这样吧，把CMFC和她妹妹都嫁给你吧。时间长了你自己会作出正确的选择。“
VC程序员：”算了吧，MFC才是我的最爱。对了，昨天我还跟您邻居家姑爷吵了一架，竟然敢鄙视MFC。”
自己也算是个资深的MFC开发者了，越来越感觉MFC的没落，现在这两年也是渐渐远离MFC相关的开发项目，做点其他的。
楼主说的很对，建议新人不要深入学习了，不是MFC要被淘汰了，而是现在开发的主流趋势是多终端的，主要集中在移动端和服务端，所以只做桌面程序的市场是越来越小了。
回复楼主，我从1997年使用MFC编程，到现在已经18年了，可是从来没觉得它落后了，关键是我这18年来只编写一个软件这个软件长度已经接近100万行C++代码了，里面自己建立数据库系统、自己建立编译器、自己建立人机界面开发平台等等，我现在用一个小时的时间开发的功能，估计你用C#、Java等语言一周都做不出来。
我现在上班基本没人管，工资应该还行吧，每天就花一点时间编编程序，怎么编写程序自己定，怎么做都可以，你说MFC落后吗？关键是你采用MFC编写什么程序？比如：你给我编写一个桥梁载荷计算的程序，你是用什么编写好呢？要么你用MFC编写，或者你用MFC开发的平台软件ANSYS等来做，你还指望采用C#，Java能开发出来吗？？？？？
MFC适合于开发复杂的二次应用平台，定位是比较高端的，简单点说，你如果要想开发一个类似EXCEL，浏览器等平台软件的程序，你这时候只能用MFC了，而且你编写完成后，你10年内都不容易落后！！！！！
MFC诞生的时候是1992年，C++还没发明出命名空间，标准模版库也没有进入C++标准。
从现代C++的眼光来看，MFC是丑陋的设计。被抛弃是必然的。
说的有理。语言会影响思维方式。MFC还停留在史前C++时代。
刚刚还有人在群里面发招聘信息 cocos2d 1年经验10k-15k，现在移动端薪水炒得是火热啊。
MFC呢？绝大多数都是维护历史系统吧，薪水能给到多少呢？
市场10多年前都转到Web了，现在更是向移动端转变。这些平台，别说mfc Win32的技术都用不上。
越讨论越深入，但也越离题了。又回到了：语言只是工具，解决问题才是核心；语言都是相通的，精通一门语言后，学习其它的很快；.......
标题主要是针对新手，这个很重要。现在依然有很多搞mfc拿着很高工资的人，也有很多搞mfc分分钟就转java、c#的人，也有很多没搞mfc，但随时可以上手的人，但这些人都不是新手。
对于新手要知道，mfc 是过时的，微软自家都不更新了；现在搞mfc的人很少了，工作需求也很少了；现在是移动、互联网、大数据、物联网的时代，那么多技术可以学习，没必要选一个过时的东西。
作为一个学过mfc的人，确实佩服楼主写那么多、回复那么多。跟楼主一样，劝新人，换一种技术学习。
pc出货量持续下跌，手机终端已经成为人们连接互联网的最主要手段，传统pc上的应用越来越少，各种开发工具层出不穷。死抱着只能做微软的windows下的终端应用开发的mfc真的符合这个时代的发展要求么？
如果你已经在mfc浸淫了数年，有所成就，不反对你继续使用。如果是新手还是绕道的好，不说开源阵营的qt，java等等可以选择，就是微软大一统的windows10对mfc的支持也是有限的。
与时俱进才是王道。
自己看看都说了些啥。win10和MFC有毛关系？难不成在win10上无法使用MFC开发程序，或者开发出的程序在win10上运行不了？笑死人了。
MFC程序仍然能运行在Windows 10的PC上，不过8英寸以下的Windows，MFC还能运行吗？借用你的语气：“8英寸以下和MFC有毛关系？笑死人了。”是，跟MFC是没有关系，你告诉我为什么新出来的技术都跟MFC没关系呢？不这进一步佐证MFC的面越来越窄，微软已经把8英寸以下Windows 10免费，这是多大的市场？
请问博主如何学习COM,ATL,WTL。明说学这些东西就是为了进某公司。。。（但这些东西要完全自学）。 在下对Windows编程刚入道(不超过3个月)，看过《Windows程序设计》，《C++templates》,《How to pragmme C++》,《C++ primer plus》,会一点MFC(拖拉控件的编程)，请问如何学习COM,ATL,WTL这些东西，我隐隐觉得这些东西（ATL,WTL,MFC）许多组件名字相同，博主能给小白点建议么，感觉（COM,ATL,WTL,MFC）小公司不会采用，技术门槛高，而我又是自学，资料感觉少而老，但是C#这些东西大公司又不会采用，目的就是进莫公司，希望给点建议，非常感谢
COM,ATL,WTL 这几个都不建议学了，不行就换个公司，学了以后用处也不大
嵌入式，wince，MFC使用中。。
桌面平台，我用c++ builder，安卓平台，我用c++ builder，IOS平台，我用c++ builder.....
在嵌入式上，由于硬件机能的限制（CPU频率低，资源紧张），用C#有时候无法完成任务，虽然WINCE 5.0，6.0及以上，都支持C#开发的.NET程序，但是运行起来，那嵌入式板子真心操不起来啊，操不起来。。。。
一个200MHZ的CPU，要串口告诉通信，要ISA采集波形，要支撑1204*768分辨率的屏幕显示，画图，这时候除了MFC，我想不到另一个在开发效率，维护成本，运行速度上能平衡的方案了。当然，你要是不考虑开发周期，直接上C语言，汇编什么的，就当我没说。。
老的板子还会在wince上继续做下去，与MFC算是相濡以沫吧，关键是wince也不发展了，不管是嵌入式，还是桌面，还是其它，全都统一成windows 10了。我们也看到，跟MFC同一个时代的c++ builder转型初步成功了，不过我们也有一丝担忧，在开发语言、框架和工具纷纷走向开源和免费的路上，未来c++ builder的商业模式还能走多远？即使历史上，MFC跟VCL比也差多了，只不过MFC挂在微软的旗下而已。
我觉得推荐学MFC的人就是故意想误人子弟(因为他自己被这个落伍的技术套牢了)。对于it行业新人，iOS、安卓、js、这些技术不去学非要学落伍的要淘汰的技术。真是蛋疼啊。我曾经也是从MFC的坑里跳出来了，尼玛现在新系统谁还用MFC啊。现在新项目都重点放在移动端、web端。尼玛学MFC还不如去学微信公众号开发。
一句话说了：现在新手还学MFC。。简直是傻逼。。
mfc早过时了，新人还是远离一点好
mfc，没饭吃。新人完全没必要学习mfc，这种古董的东西了。如果是学习windows编程，应该从基本的win32开始。mfc现在完全不符合当下高要求的用户体验。win32 + html + css， direct-ui 此类技术的应用，更是让mfc更是被边缘了
看到帖子很高兴，看完帖子很悲哀。
都说中国进行工业化升级，没想到楼主依然是官僚体系的思考方式，而且这种思考方式在我的世界里还是很多，做任何事情都要抨击别人，总是以自己的尺子去测量世界，不符合自己尺子的人都是错的。摆正位置，统一思想，这种官场上的东西真是害死工业界的小白们。
我们现在开上汽车了，自行车就过时了，就要被淘汰了。我们吃上肯德基，麦当劳，就告别大米白面了吗？整个国家的软件水平都在一条线上吗？北上广不用的技术，去那些二三线城市也不用了吗？你所在的计算机领域不用的东西，别的领域就不用了吗？
你的世界太小了，你的视界太狭隘了，去看看工业一线的企业吧，他们很需要那些物美价廉的MFC软件的，MFC确实是已经过气了，但是真的没有过时。
小资程序员的通病，眼界小，心眼窄，确总是觉得自己就是全世界
离开应用场景和行业来讨论什么语言，什么框架，什么库有没有用，过没过时，是不准确的
写windows界面程序，要求发布的是本机代码，那用什么好呢？
我用win32API 写的，不过开发效率确实低
使用MFC并不是因为MFC好用，而是因为在要求本机代码发布的windows软件开发过程中，能使用的图形界面库寥寥无几。Delphi的本机代码版本早已不再继续开发，Qt因为过于臃肿。至于wxWidget则直接是MFC的封装。至于所谓的.Net Native，离开winRT就不能用了，更何况winRT软件只能在微软商店发布。
winRT对win7和XP无法支持。放弃win7和XP市场是不可能做到的。另外.NET NATIVE 并非纯正本机代码，而是缓存了预编译的部分，避免打开时重复编译。另外.NET NATIVE不能离开.NET FRAMWORK运行，而且运行效率与本机代码相比还是有差距。
可能大家各自的圈子不一样，所以观察到的现象也不尽相同。我怎么觉得，Delphi可比MFC惨多了？
MFC至少在工控领域还是能够很经常地见到的，Delphi至少在我周围的圈子里已经绝迹很久很久了。
史前的一场大决战，巨硬派了MFC，破筐派delphi，二将正杀得难解难分，突然四面楚歌，再一看旌旗招展，原来双方早已身陷重重的包围之中。破筐想逃，却逃不出去，只好带C++Builder一起杀入重围与delphi并肩作战，左突右冲，损失极其惨重。巨硬一看各路诸侯来势凶猛，自知抵挡不住，只好让MFC断后，自己带大队人马杀出一条血路，巨硬大呼：“吾头尚在否?吾头尚在否?”后来，背靠Windows天险，厉兵秣马，准备另辟蹊径，来年再战。可怜MFC孤军作战，没有援军，没有补给，也没有撤退的集结号，只好拼命了。
我想提醒各位，不要总是以 IT 人的立场来看待问题，在工程师中，除了 IT 工程师，还有很多其他的工程师，比如说航空工程师、自控工程师、电气工程师，他们也会是Visual C++的用户，不妨也听听他们的意见，听听他们怎么说，这样你的想法就不会那么偏激。反正，不管你们怎么唱衰MFC，但MFC一时半会儿也死不了，再过十年也死不了，甚至到某些人将来已经从程序员、软件工程师的职位上改行去做别的事情、完全脱离了IT业，到那时MFC说不定也还活得很好，在工控领域、在航空领域、在能源化工生产制造领域，依然发挥着中坚力量。
废话那么多，拿工资出来说事就好了。
学校学MFC的，到了公司基本用不上，大家都有自家UI库，MFC从来都是个烂摊子。
要理解设计模式，直接学设计模式就好；要理解windows api就学win32。
当然，有些山顶洞人程序员和公司，还在用MFC我就不知道了。
还有句话给新人：来说是非者，即是是非人
win98没玩熟，就追捧win2000的人多得很
win2000没用出啥头绪，就追捧winXP的人多得很
winXP才一知半解，就改道追捧win7的人多得很
这些人现在正追捧win10呢，他们的见树呢？他们的应用呢？
当然，今天，你不可能再拿WIN98给别人装机。
但你觉得追捧win10就正确吗？
其实，追求核心的人牢牢抓住本质，
能用win98避开缺陷完成目标，也不会因用WIN10的臃肿而阻碍目标
绝对不会因为一个所谓的过时和所谓的流行的概念就盲从。
只有表象才会过时，本质不会
提出过时和流行概念的人，或许有几分道理
但绝对都只是一些浮于表象的投机之徒
用投机的心态去找的饭碗真的能吃饱吗？？？
用MFC的(虽然我不用,用的是WTL),可以用擅长的C++语言, 可以方便的调用C/C++类库（系统或第3方）, 可以嵌入各种脚本语言,可以方便极致的优化.
当然如果一开始就学的C#, 真的没有必要再学MFC.
当然qt作为界面开发也行, 但是这个库实在过于庞大, 和STL也没什么事了，所以我推荐如果要用, 可以用WTL开发界面, 简单的对Win32封装.而且只是界面, 其他库完全可以用stl或第3方库什么的.
很奇怪，好像学MFC都不学别的了. 搞技术还是多学点好, 原理是相通的, 设计是可以借鉴的.
Windows搞界面就选这几个,如果是C++为主要语言:
wtl,duilib,qt(qt真心不建议,qt的学习成本也不低,不过好在难逆向)
不建议用wxWidgets, 搞了wxWidgets 3年,不是所说的那么容易跨平台,很多bug,不稳定, 莫名其妙的崩溃找源代码修改编译真是费时费力. 开发速度真没有使用本地sdk开发高, 很难定制复杂的控件和界面. 定制了复杂的控件后崩溃发现它的基础的类库有bug, 后悔浪费那3年时间.
如今流行拖拉机耕地，你丫到云贵高原耕一个我看看？
反驳哥的极端证明不了你们的极端，因为哥的极端本来就是拿来放大你们的极端的
你们说选择任何一样都可以完成MFC的
我只想问你们选择的任何一样流行的东西又有那一样是MFC做不到的？？？？
不要再自以为是的鼓吹流行与淘汰了，图样图森破
高铁消灭不了飞机
飞机消灭不了汽车
汽车流行了，消灭不了摩托
摩托流行了，消灭不了自行车
自行车消灭不了马
马也消灭不了骆驼
你看不到自行车，那是因为你只生活在城市的中心
在你的生活圈子看不到的，不是数量减少了，而是你座井里了
马的功能有很多种，不管是代步还是作为食物还是作为运输还是作为生态之一，它都不是地球的必须
按你丫的思维，不必须的就没有必要了，那马早绝种了。
可以用马代步，也可以用汽车。没必要非得会骑马，才能学开车。对于绝大多数而言，直接学开汽车是个省时省力有效的方案。
各有所长
你要是做电商系统，作为一个架构师
你需要会分布式缓存，分布式文件系统，cdn，这些都是c/c++写的
还包括分布式消息中间件，配置服务器，数据库分表分库中间件,这些是java写得
消息推送服务器物，现在这个一般用go写
还有基于dock的容器布置技术，这是用python写得
当然了，数据到了pb规模，牛逼的团队还需要自己写分布式数据库（比如淘宝的oceanbase,那可是一帮搞java的人，用c++写出来的）
把这些都熟悉了，才可以搞什么web，服务层的分层设计，支持pc ，手机的api接口
然后，手机你又要基本熟悉andriod的java和ios的oc/swift
现在的互联网公司，架构师需要熟悉多种语言和技术
并不局限于java 或 c++
Windows编程革命简史 | | 酷 壳 - CoolShell https://coolshell.cn/articles/3008.html
主要部分来说是这样，CDC是HDC的封闭，CWnd是HWND的封装，CSocket等等。。。。但CDocument什么的却不是内核对象的封装，想要深入学习内核，还得学习API，而不是在MFC里绕。当然，要不要学Win32 API，还得看工作需要，如果是开发360之类的软件，那是必须要学的。如果是ERP之类的软件，你用Win32 API来开发界面，那就舍近求远了。
MFC上手慢，通常是错误的学习顺序。
C++ Win32SDK，不说精通，懂得差不多的话。MFC只需要一个星期。
时间关系我就简写了，你说的STA，MTA这些，clr的一个三级命名空间下都涉及到，并且还要研究managed与unmanaged之间的内存，线程，运行单元等的关系。这是不是也不浅？最大的区别在于，.Net（WinRT）想快速出成果的时候可以轻装上阵，而要深入又可以随时间循序渐进、层层深入，进退自如多好呀。所以MFC不是通往Windows核心的唯一道路，并且现在来看，甚至可以说是一条古道。当然对于已经掌握的老手而言，已经摸爬滚打练出来了，0成本 ，不需要进一步的时间投资，所以不需要彻底放弃。
再换个角度来讲，即使有的人压根没接触过这些，学的是Linux，gcc，java等等，照样是高手，所涉及到的技术更深。MFC作为起步的一种方式，只能说作为经验，难道还有相对的优越感吗？
另外，难道学MFC的人境界比学别的境界更高？这个我理解不了，我只能理解MFC比VB6在技术上更有深度。我理解的学习境界，“三人行，必有我师焉”是一种境界，“人不知而不愠”则又是另外一种境界了。
作为一个在IT界摸爬滚打了10来年的老人来说，我还是比较同意楼主的观点的。想当年也看侯捷的深入浅出MFC看得如痴如醉，不过就现在来看的确MFC属于过时的技术，市场上老板才不会纠结一定要用什么技术做出产品，说到底都是生产力，你能用更少时间更少预算做出更好产品才是老板关心的，从这个层面出发MFC不是一个好选择。再说MFC带给我们从思想上的改进也没那么明显，如果磨练编程思维宁可去学不会被淘汰的譬如算法，数据结构，做产品要效率还是要用现代的语言和框架。所以MFC在编程效率上慢(不是运行效率)，在思想提高上也不明显，加上招工机会少，放弃学习反而是比较明智的选择。
当然不是必须的，还有C++/CLI，QT，Win32，...
但是MFC比CLI门槛低，比QT资料多，比Win32开发快，所以对于用C++的新手，MFC是最好的选择。
Windows 2000泄露的源代码，我记得有不少是MFC的。
Visual Studio 6，2003，2005，2008，我一直以为是MFC界面。
Visual Studio 2010，2012，2013，2015，我一直以为是WPF界面。
Office 97, 2000，2003，我一直以为是MFC界面。用Spy++看过，有窗口句柄，至少不全是DirectUI。
Office 2007，2010，明显风格不同于以前，属于DirectUI。
Office 2013，使用了.NET框架，但界面是WPF还是DirectUI的呢？
其实无所谓了，我想如果微软还在用DirectUI，DirectUI的界面描述语言也应该是Xaml了，Xaml也是DirectUI不断发展的成果。
以上都是我的假想，不去考古了，欢迎拍醒，非常感谢。。
VS2002 - VS2008 IDE 是一套代码发展过来的 .net 的
VS2010 - VS2015 IDE 是又重写的，应该是WPF。
像是记事本 画图 扫雷 纸牌之类的，都是直接 windows sdk。
office 可以肯定地不是基于MFC的东西。
MFC更重要的是一种编程思想，SDK是C的WIn API, MFC是C++的 Win API封装，没MFC, C++下的Windows编程就没法展开。承认现在C#, Java很火，但并不影响C++在工业基础性软件方面的调用。目前很多MFC的标准UI库已经做得很完善了。MS自己的Office, Visual Studio都MFC编写的，这没什么异议，很早就有定论。
比较好的MFC基础库有：
1、Codejock的Xtreme Toolkit Pro.
2、BCGSoft的BCGControlBar Pro.
3.、UCanCode的E-Form++ (重点推荐)