WPF與WINFORM的選擇

微軟曾經對WPF（代號Avalon）抱很大的指望——新一代的華麗用戶界面平臺，一統Web應用和桌面應用，Flash殺手，儘管微軟口頭上不認可。幾年下來，WPF確實實現了當初的預期的大部分功能，但離稱霸軟件開發領域還有不小的距離。不過，剛轉到 WinForm上一兩年的開發人員們都很困惑，WinForm究竟還有沒有將來。微軟只是模糊地說短時間內仍是WinForm，長期是WPF。想一想「維納斯」，「TabletPC」，「Hailstorm」，「IE Channels」等等就知道這位老大的話不能全信。到底何去何從就仁者見仁智者見智了。

英文開發社區內有句流行的話，叫「No silver bullet」，就是說沒有萬能，沒有一個工具或方法能完美地解決全部的問題。一樣這對WPF也適用。與其說WPF是WinForm的替代品，它更像DHTML和ASP.NET。誇張一點說，若是要給微軟的技術畫個家譜的話，DHTML就是WPF的直系親屬。WPF裏的大量核心概念和結構，如屬性引擎、事件模型等，都是繼承自 DHTML，最大的一個不一樣是外觀和控件邏輯的分離。WPF應用和DHTML應用（HTA）的類似性也很是大，不一樣點是WPF應用能夠徹底脫離IE。也就是說，WPF和網頁、ASP.NET、SVG是一套體系，能夠比做XML版的Flash，而和WinForm徹底不一樣。WPF的長項應該是網頁式應用，固然它也能夠用來作別的東西，就像Ajax能夠作在線文本編輯器同樣。

也許有人還沒據說過DHTML。DHTML即Dynamic HTML，是微軟在90年代末在IE4裏支持的擴展了的HTML，主要特徵就是能夠動態修改網頁上對象的屬性，並且具備相似Flash裏的時間線，能夠作動態的網頁。缺點是難於開發和調試。後來主要被用來作翻轉按鈕。DHTML的一個頁面集合和腳本資源一塊兒能夠打包成HTA應用，HTA應用能夠在本機以及網絡上使用。但從如今還有多少人記得DHTML就知道這東西沒成才。

回到WPF，WPF只在XP和Vista上有完整的支持，在其餘平臺和瀏覽器下，微軟提供了WPF/E（開發代號）。WPF/E的程序是非編譯的，就是說是發佈源碼的，和HTML加JavaScript同樣。另外WPF/E目前只支持JavaScript。那麼，WPF/E能用來作什麼應用你們也就內心明白了。要在WPF/E和Flash間選擇的話，只要想一想XML和壓縮的二進制文件的區別就好了，如今幾兆的Flash比比皆是，改用XML格式的話會有多大，諸位內心明白。不過要是個網頁Form應用的話，WPF/E確實比Flash更強一些，不過有Ajax在，殺雞未必要用牛刀。若是你的應用只支持XP 和Vista，那麼你能夠獲得WPF的所有優點。

WPF有三種應用模式：應用、瀏覽應用、文檔應用。應用就是通常的窗口應用，瀏覽應用就是象網頁同樣的一頁一頁的應用，文檔應用是用來顯示內容的瀏覽應用功能子集，而不是MVC模型。通常應用其實也就是每一個頁面擁有一個獨立的窗口。估計VB用戶想到了當年的html控件，Delphi用戶想到了 IntraWeb。簡單的理解就是把WinForm界面換成了網頁，固然這個網頁的功能比HTML強得多，也複雜得多。

WPF是一套很複雜的體系，它的界面能夠用代碼生成，不過絕大多數人都會用XAML來生成。XAML能夠認爲是WPF的HTML。制定標準的人老是說 XML是可讀的，但多數人認爲它是用來給機器讀的。XMAL基於XML，同時作了至關的擴展以彌補功能的不足。要手寫XAML，必須瞭解WPF，瞭解 XML（namespace，link等等），瞭解XAML的規則，瞭解XAML擴展的語法，可以記住大量的標識符和引用關係。就像今天人們大多再也不手寫 HTML同樣，人們大多不會願意去手寫更復雜的XAML。並且按照微軟的設計目標，WPF要將界面設計和程序邏輯分開，交給不一樣的專業人員去作。也就是說，界面的設計是要交給美工的。相信我，找一個可以手寫XAML的美工很難。微軟爲此提供了Expression系列軟件，固然不是免費的。固然 VisualStudio裏也有必定程度的支持，但這意味着由程序員來作靈活複雜的界面，更容易作出醜陋的界面；或者讓美工來用 VisualStudio，功能有限並且有點昂貴。固然也可能有個不錯的UI程序員，一箭雙鵰；或者老老實實地作簡單樸素的界面，之後有機會再找美工潤色。

程序員都喜歡談論速度。WPF是能夠硬件加速的，在DirectX 9級顯卡和安裝了較新的驅動的狀況下，WPF會獲得部分或徹底的硬件加速。WinForm是基於GDI+的，沒有硬件加速，只有v2.0裏的非兼容模式下的文本是經過GDI加速的。因此，長遠來講，WPF有更好的性能。

那麼如今回到最初的問題，WPF和WinForm，賭注該壓哪一邊。編輯器類程序是難以移植到WPF的，如World、Excel、 PowerPoint、Photoshop、IDE等。顯示類和通常的商務類應用都是能夠移植的，現有的Web應用都是可移植的。也就是說，WPF的應用範圍和Ajax、Flash是有很大重合的，WPF的競爭力就是在和代碼的集成上。隨着Adobe加緊升級Flash的應用功能，一種可能的結果是WPF 和Flash壓縮了Ajax的生存空間，WPF/E沒有得到足夠的支持，WPF成爲Windows專用的應用，Flash做爲跨平臺方案存在。而對 WinForm程序來說，嵌入一些WPF內容是容易的。在WPF前途未卜的狀況下，WinForm仍然是目前通常應用最穩妥的途徑。

[討論]對比MFC ，Winform ，WPF

對比MFC ，Winform ，WPF
MFC 生成本機代碼，天然是很快。但是，消息循環，減緩了界面顯示速度。

winform 封裝了 win32 的api，屢次進行P/invoke 操做 （大部分使用p/invoke操做封裝），速度慢。

wpf是一種新的模型，再也不使用win32 模型，本身新建模型，使用dx 做爲新的顯示技術，直接訪問驅動程序，加快了運行速度，但是，這種模型，須要支持dx 9 的顯卡，硬件要求高（你還能找到現代機器不支持dx9 的嗎？）

開發效率上，MFC <WPF <winform

儘管MFC開發界面執行效率高可是開發效率低，做爲如今的項目開發來講時間跟開發效率每每能決定項目的成敗，因此除非有特別的需求，不然都回儘可能避免用mfc來作開發，MFC只是一個弱封裝器。

開發成本，MFC〉wpf〉winform

用MFC開發成本過高，對開發者能力要求更高，做爲客服固然但願開發的費用越少越好，開發者固然但願錢賺得越多越好，這樣一比，這也是MFC沒落的一個很大的緣由。

界面執行效率上，MFC==WPF〉winform

隨着計算機硬件的性能提升，多核cpu的普及，它們的差距會愈來愈小。

開發靈活性上：wpf〉MFC〉winform

美觀上：Wpf〉winform〉MFC

這一項中MFC下要開發出一個華麗的ui極其困難，也許你能夠說你能夠用控件，可是商業開發控件是要收費的！！Wpf很容易就能夠作出vista那樣的ui特效。mfc要寫出這種效果不知要寫到何年何月。
這樣一來MFC存在的價值就更低了。效率和美觀不如Wpf，開發效率又不如winform，預計不出10年，隨着vista取代xp，mfc將會退出歷史舞臺。

內存使用上：wpf〉winform〉MFC

隨着計算機硬件的性能提升wpf這個缺點會被忽略。

使用範圍：wpf〉MFC==winform

有以上可知：WPF 大有取代winform 和MFC之勢，從將來net的發展來看，MFC之後只會變成一種經典，做爲一種技術來供開發者學習，winform和WPF二者會並存發展，但最終都會被WPF取代，最終實現桌面應用程序和瀏覽器應用程序的統一。

http://kwon.iteye.com/blog/1250454