转自http://blog.csdn.net/Felomeng/archive/2011/03/11/6239264.aspx写得不错,自己翻译一下,想以后时不时地提醒俺,不要偏离自己的方向
很多人来到IRC(互联网多线交谈)咨询“MFC和API,学哪一个更好?”,在他们做项目初期有涉及过MFC或者API,或者其他人在谈论它,所以很多人并不希望去说到底MFC不好还是API差劲的话。
这些议论的基本观点是:
API非常难
MFC让人很困惑
API太多的代码
MFC很复杂
API不是面对对象的
MFC“踢了我的小狗”
API“拐走我的女友”
。。。
我的回答
在我看来,说用哪个都没什么意义,关键是选择合适的框架来完成适合的任务。
首先来说下API和MFC分别是什么,API是通用术语,表示应用程序设计接口(Application Programming Interface),而在windows环境下,它特指windows API,它是最底层的交互,处于应用程序和windows操作系统之间。驱动当然更底一层次了,不同的函数调用结合在一起使其井然有序。MFC是个类库,它隶属于C++类,它有很好的代码风格,这样可以减少很多不得不需要用API来做的事情。它采用了面对对象框架来构建应用程序,你可以利用它也可以不用它。因为它没有明确的目的去针对于比如MP3播放器、IRC客户端或者游戏,所以很多初学者很困惑怎样选择。
其实每个程序不管是用MFC、Delphi、Visual Basic、perl或者其他的编程语言或者框架,你都得认识到,它最终还是依赖与API的执行。很多情况下这种交互被隐藏了,所以这些事运行时间和支持库为你做的事,你不能直接地用API。一些人问道“MFC能做这啊那的,API能么?”,答案是MFC能够做的API一样可以做到,因为MFC是建立在API基础之上的。但如果做项目用API将会编写比用MFC类库更多的代码。
那什么才是合适的框架呢?作为初学者,那些刚开始接触编程的人们,我强烈建议先从API学起,直到真正掌握了windows应用程序的工作原理,并理解了所有的基本架构、消息机制、GDI(图形设备接口)、控制机制、多线程和sockets。这样你将会理解所有windows应用架构的基本原理,并可以用这些知识去用MFC、Visual Basic、或者其它的你选择的体系框架。非常重要的一点是其它的框架并没有提供所有API能提供的东西,这是因为API提供了相当多的功能,而其它框架不需要支持那些很罕见的用户从来不用的功能。所以当你需要这些功能时你应该自己加入这些API,你不能依赖与框架去做这些事情,如果你还不理解API这将会是件很繁琐困难的事情。
这样看来时不时MFC更容易些呢?一般看来它在处理常规的任务时确实更容易些,因为它减少了大量的需要本应该自己构建的代码。然而,越少的代码并不意味着更简单,如果你不理解那些你应该自己写的代码,就得去了解那些代码是如何支持你的实际工作的。初学者通常地用向导去开始应用程序,但却不懂大部分代码的含义。当你从头开始编程,不管是用API或者MFC,那时你将真正理解所有的机制因为那些你自己放在那的代码,而且你也仅仅会用那些你已经理解的特性。
另一个重要的方面是很多刚开始学win 32 API的朋友并没有很好的C++功底。试图尝试去理解用MFC来windows编程,并同时学习C++时间相当庞大的任务。而且它几乎不可能完成的,它将比那些已经拥有C++技术或者理解API的人要花费更久的时间去达到生产的水平。
总结
归根结底,我任务初学者应该先学API直到觉得自己已经理解它了,然后再去尝试了解MFC。如果这样看起来能让你有点编程的感觉并且节约了时间,就一定要尝试一下。
举个例子,如果你在没有了解API的时候,用MFC来进行你的项目,你会寻求些帮助,这些答案是如果你开始先学API就会解决的,你会问“啊?”因为你不懂怎么从API过度到MFC的机制,当然也就不会自行完成了。那时你会陷入困惑并且人们会对你的工作感到灰心,因为那些东西是你本来在用MFC之前就应该会的。
我个人更喜欢用API工作,对我来说真的舒适。但如果我计划写前端数据库,或者为主机设置的插件控制,我将会用MFC,因为它真的节省了很多那些我应该去重写的代码