MFC,QT,WPF，.NET比WIN32 API做界面有哪些優勢？

01-03

機器語言不能寫程序嗎？為什麼一提到編程語言就是彙編，C，Java，Python，PHP？難道它們不都是轉成機器語言執行的么？

Talk is cheap。請對比：

一個最簡單的Win32窗體程序：

// 太長了，略。

一個Qt實現的簡單窗體程序：

#include &

int main(int argc, char *argv[])

{

QApplication app(argc, argv);

QMainWindow win;

win.show();

return app.exec();

}

如果你的老師讓你默寫上面兩段程序，哪一個更簡單呢？

MFC主要加入了消息映射等神奇小玩意兒，而且隱藏了(w)WinMain。但很顯然，微軟都不怎麼重視了。你看看，MFC的那個logo還沒扁平化呢。

而且，當你選擇純SDK的話：

1. 比較麻煩的就是編寫消息回調函數。因為你需要從wParam、lParam中獲取自己可能用到的信息。而Windows中消息又那麼多，對不同的消息，這兩個參數含義又不一樣。所以你需要不斷地查文檔啊，查文檔。雖然，windowsx.h頭文件中那一系列神奇的宏可以在一定程度上解決這個問題；但這個例子也說明，用SDK寫程序的話，你要關注的信息太多了。

2. 很多API都有一堆參數，而你能用到的可能就那麼幾個。

原生js也能玩特效，為啥老提jQuery……哈哈……

這樣說來PHP不愧是世界上最好的語言，這一類的提法少的多?

當然了，也有一個問題是win32api以外有些東西也在編程中佔據重要作用，例如windows對富文本，http，高性能的多媒體，html的支持都需要特定的com控制項。

我個人就很喜歡win32api。另外有些人只管能開發應用，連他用的是C++都不清楚，那麼這些人只管用MFC也就不出奇了。

當然可以。

不過封裝的價值就在於

減少代碼量，尤其是重複的部分
從而減少出錯概率

快

見過Visual Basic 6.0直接調用Win32 API創建窗體的，能正常使用，但是……IDE裡面點一兩下就解決掉的事情為啥要重新寫幾百行代碼實現？難道已有的那些開發環境都是白寫的？

一個好的框架可以大大提升開發效率啊，尤其是基於這個框架上面有很多成熟的控制項之後。

基於win32 api的開發速度如果是1，

基於MFC的開發速度可能就是5，WPF就是20。

學最難的。用，最容易的。

用Win API編界面很麻煩，而MFC對Win API進行了封裝，不管是開發還是維護，比直接用Win32 API便捷多了。他們的關係就像彙編與C語言的關係那樣。所以一般編界面程序，都會用封裝好的框架，而不是直接用API。

最大的優勢就是快。快是界面設計裡邊很重要的一個因素。

使用NATIVE API來做界面也可以，但是一旦項目規模上去了，你就不可以避免的要抽象出很多功能，也就是說會變成自己寫一個界面庫了。

而且做界面庫又有很多做法，比如像MFC那樣的包一層，或者如QT,WPF那樣支持XML等現代特性。

如此種種都是為了快，即提高生產率。

一般如果特別注重界面，都會自己寫一套界面庫，就像qq，thunder,再如firefox/chrome.

餓...這個..別人在問我MFC有必要存在嗎...

能寫，太麻煩了。

規定對話框大小，名稱，聲明按鈕，位置，按鈕的組別啥的實在是太煩了。但有了mfc只要拖拖滑鼠就能畫一個出來，不用一次一次的debug調整了。

可以，不過開發效率真的是低了點。

如果是自己寫著玩的小軟體小工具，我比較傾向於用API，感覺靈活一點，也讓自己學習得多一點。

如果是做項目，或者幫別人做些什麼的，果斷用MFC/Qt，用起來的確比較爽，開發速度也快一些。

如果是學習，建議從win32 api 入手，上層都是底層的封裝，弄明白底層利於知識的向外拓展。像win系的繪圖gdi，消息傳遞機制，窗口控制項等在某種程度上來說都是從win32 api上衍生出來的。

但是，在實際開發過程中，考慮到以下但不限於的幾個原因，直接用win32 api進行開發的已經很少很少很少很少很少了。。。

1：提高開發效率。

2：減少重複代碼。

3：降低出錯風險。

4：降低維護成本。

別說win32 api，mfc已經多次被問有沒有存在的意義了。。。

封裝成.net類庫多好啊