Winform、WPF、Silverlight、MFC區別與聯絡
WinForm
在Windows中，諸如窗體繪製等功能由GDI（圖形裝置介面）實現，放在作業系統核心中。Windows Forms在底層使用的是GDI+。GDI+是GDI的“面向物件包裝”，使用C++實現。.NET Windows Forms應用程式中使用的GDI+其實是在C++實現的非託管程式碼之上又包了一層，從而讓我們能使用C#這樣的託管程式語言呼叫GDI+功能繪圖。
WPF
WPF底層使用的是DirectX，(Direct
eXtension，簡稱DX）是由微軟公司建立的多媒體程式設計介面。由C++程式語言實現，遵循COM。)就是通常用來開發遊戲的那個DirectX。WPF與Windows
Forms
當然，出於相容目的，Windows Forms與WPF將長期並存，可以把它們看成是兩套獨立的介面技術。
此外，從技術的角度，WPF比WinForm先進是不容置疑的。
在Windows GDI或WinForm開發中複雜的GUI應用程式，會使用的大量的控制元件，如Grid等。而每個控制元件或Grid
cell都是一個小 視窗，會使用一個Window handle，儘管控制元件廠商提供了很多優化辦法，但還是會碰到Out of Memory或"Error Create Window handle"，而導致程式退出。
WPF徹底改變了控制元件顯示的模式，控制元件不在使用視窗，也就不會佔用Window handle。理論上，如果一個WPF只有一個主視窗的話，WPF只會使用一個Window
handle（如果忽略用於Dispatcher的隱藏視窗的話）。所以WPF GUI程式不會出現Window handle不夠用的情況。
2、多執行緒的處理
在WinForm程式開發時，最頭疼的一個問題就是，worker執行緒修改控制元件的屬性而導致程式崩潰，而且這種非法操作並不是每次都失敗。WinForm控制元件提供了InvokeRequired屬性來判斷當前執行緒是不是控制元件建立執行緒。問題是當控制元件樹很深時，這個屬性會比較慢。
WPF開始設計的時候，就考慮到了多執行緒的問題。大部分的WPF類都繼承於DispatcherObject。DispatcherObject實際就是對Dispatcher的一個簡單封裝。Dispatcher提供了類似InvokeRequired的方法(CheckAccess)。這個方法只是比較執行緒的ID，所以會很快。另外，Dispatcher提供了優先佇列，非同步呼叫，Timer等功能，簡化了開發多執行緒GUI程式。
3、控制元件的Composition
在WinForm如果要實現一個有Checkbox的下拉選單，將不得不處理複雜的Window訊息。而通過WPF控制元件的Content
Model和Layout系統，WPF控制元件可以包括任何型別的控制元件，甚至.Net CLR物件。很多現代的控制元件廠商也提供了Composition的控制元件，實現方法和WPF的Content模型也比較相似。WPF開發團隊應該借鑑了Infragistics的很多想法。有了這個基礎，開發新的WPF控制元件更加簡單了。
4、XAML
個人覺得XAML應該是WPF中比較劃時代的東西。通過XAML，我們可以用文字的方式描述複雜的Object
Graph。這個想法在VB中就有了，不過XAML更簡化，以便於使用工具來生成XAML。通過Command，Routing Event等機制，介面設計人員和程式設計師有比較清楚的界限。
4、Dependency Property
在WinForm開發中，經常碰到的問題就是一個控制元件的值變了，其他控制元件也會跟著改變。解決辦法，要不是通過寫程式碼，要不是通過資料繫結，前者是介面和程式碼沒法分開，後者還不夠靈活。而WPF在這方面通過XAML可以簡單的把相關的屬性聯絡起來，通過Extension可以實現複雜的繫結關係。
總的來說，WPF應該是GUI發展的一個延續，原來GUI中複雜的東西，現在通過簡單的文字就可以實現。
Silverlight
Silverlight在API層可以看成是WPF的子集，但事實上除了這點之外，Silverlight與WPF並沒有任何聯絡。因為Silverlight應用程式不依賴於.NET Framework，只要使用者計算機（或手機）安裝有Silverlight執行環境（比如使用者通過網際網路給瀏覽器添加了Silverlight外掛），就可以跑Silverlight應用程式，並不要求使用者安裝龐大的.NET Framework。Silverlight執行時環境在API層面也可以看成是標準.NET Framework的功能子集，但它完全是重新寫過的，獨立於標準的.NET Framework，雖然為了方便應用程式開發，微軟努力保持兩者在API層面的一致性，但並不排除Silverlight執行時環境日後會擁有全新的為.NET標準環境所不具備的功能。
Windows Forms/WPF/Silverlight這三者其實是獨立發展的三個技術領域，只不過微軟出於方便開發的目的，有意讓Silverlight與WPF在應用層面開發體驗（甚至包括大部分應用層程式碼）高度一致罷了。
從開發角度來看，Windows Forms已有多年的歷史，高度成熟，擁有大量的第三方控制元件等各種資源，如果開發“標準”與“通用”介面型別的Windows應用程式，使用它可以獲得較高的開發效率和不錯的執行效能。
WPF的長處在於它可以開發非常“個性化”的Windows應用程式，你可以不受任何限制地實現你所能“夢想”到的各種使用者介面，而且在動畫等多媒體方面，WPF優於Windows Forms，另外，WPF的資料繫結機制也比WindowsForms要強大和靈活。WPF的短處在於它對計算機硬體的要求較高，對於硬體配置較低的計算機，其執行效能不如Windows Forms版本。就目前來看，WPF的最佳平臺是Windows 7。
Windows Forms和WPF主要用於開發桌面應用程式，Silverlight主要戰場是網際網路，通常用它來開發RIA（豐富網際網路程式）的網際網路應用程式，或者是跑在手機等智慧移動裝置上的應用程式。可以這樣說，會WPF，不費太多力氣，就可以轉去開發Silverlight應用程式，兩者實在是太相似了，特別是介面層程式碼，由於都使用XAML，這使我們可以比較容易地為某一應用程式同時開發“桌面版”、“手機版”和“瀏覽器版”三種版本，而這三種版本其使用者介面都可以擁有一致的外觀和使用者使用體驗。
MFC
微軟基礎類庫（英語：Microsoft Foundation Classes，簡稱MFC）是一個微軟公司提供的類庫（class libraries），以C++類的形式封裝了Windows API，並且包含一個應用程式框架，以減少應用程式開發人員的工作量。其中包含的類包含大量Windows控制代碼封裝類和很多Windows的內建控制元件和元件的封裝類。
對比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取代，最終實現桌面應用程式和瀏覽器應用程式的統一。