????? 在何時使用WPF，何時使用Silverlight的問題上，很多人備感困惑。為項目選擇正確的技術取決于應用程序的需求，以及WPF和Silverlight能力的不同之處。
　　Silverlight最初稱為WPF/E（E來自于Everywhere的首字母），是面向運行在瀏覽器中的Web應用程序的一個WPF子集。如今，Silverlight以其快速的開發周期廣為所知，且持續得到眾人的關注，很多人認為它會成為微軟未來的重要開發平臺。Mike Strobel認為微軟對WPF/Silverlight的考慮有一些混亂。

我認為最重要的事情，是提升WPF本身的影響。微軟應該推動WPF成為富桌面應用程序的“核心”平臺。然而恰恰相反，微軟此時正推進Silverlight成為這樣的平臺。這會誤導那些對兩個平臺都陌生，且不明白Silverlight不兼容標準.NET函數庫的人。

　　某些人則認為WPF就快消亡了，不過Brian Noyes，一個微軟區域技術領袖（Microsoft Regional Director）及微軟最有價值專家（MVP），相信至少在未來幾年不會出現這種情況。為了證明對WPF的這種看法，Noyes在如下幾個方面強調了WPF和Silverlight之間的一些重要不同點：? 特性 WPF Silverlight
文件訪問 無限制 可訪問用戶文件夾：我的文檔、我的照片、我的視頻等
打印 具有很多選項，可訪問打印對話框、打印隊列等 需編程打印UI元素
文檔編輯 支持流文檔和固定文檔，有RichTextBox編輯支持，并能和流文檔進行集成 RichTextArea具備WPF的RichTextBox的大部分功能
命令 支持在按鈕、超鏈接和菜單項上觸發命令，鍵盤快捷鍵的輸入可綁定到命令上，可實現路由命令 支持在按鈕、超鏈接和上下文菜單項上觸發命令，無輸入綁定，無路由命令
通信 支持WCF的完整功能，能夠調用和托管任何類型的服務，支持完整的安全選項和其他WS-*協議，支持REST和很多種低級通信方式 有限的WCF客戶端功能子集，不能在客戶端上暴露服務，支持不安全TCP或HTTP協議，比WCF客戶端弱的雙向通信（只能使用HTTP或不安全TCP），支持某些socket級的功能，在很多部署場景中必須考慮跨域訪問問題。
剪貼板 任何可序列化的對象 只支持文本
拖拽 任何東西 只能是文件
外部設備 有驅動、COM、Win32或通信協議支持的任何設備 網絡攝像頭、麥克風和有COM API或通信協議支持的設備
輸入 鍵盤、鼠標、手寫筆、觸摸屏，基本沒有任何限制 必須在信任提升的OOB中，全屏時才能獲得完整的鍵盤支持

　　在WPF和Silverlight中還有一些不同的基本功能，這也可幫助大家來決定使用哪種技術。下面的例子，是一些開發人員做出選擇的解釋。
　　Joe Gilkey在回答選擇WPF而非Silverlight的問題時，解釋了它的公司為何在一個項目中選擇了WPF，而在另外項目中選擇Silverlight：

在規劃我們的軟件產品時，確實遇到了這樣的問題。對于我們而言，決定因素是是否需要訪問本地硬件，以及（或者）本地數據庫。我們的主打產品，需要在本地100%地運行。我們需要在本地SQL數據庫中緩存信息，并且要訪問一些硬件設備（GPS接收器、串口、WCF點對點通道、同步服務等等）。那個產品就由WPF來編寫。而其他兩個開發之中的產品，不用在本地保存信息（除了使用獨立存儲區），所以我們轉而使用Silverlight。兩個Silverlight產品都支持脫離瀏覽器安裝方式。WPF應用程序的另外一個決定因素是對觸摸的支持更加友好。感謝Surface團隊，幫助我們在WPF應用程序中使用針對Windows Touch功能的Surface Toolkit。

　　另外一個開發人員，Jeff解釋了為什么他的公司一開始使用WPF開發的項目后來又轉用Silverlight：

一年前，我們使用WPF開發了多媒體發送系統的自定義客戶端。明年，我們將用Silverlight應用程序來替換這個WPF客戶端。為什么？目前我們的大部分應用程序都是基于Web/瀏覽器的，不過我們也需要一個靜態客戶端來處理硬件交互和一些相對復雜的問題。現在，Silverlight具有的OOB模式意味著我們能夠通過COM來連接本地硬件，這樣問題就迎刃而解。為什么Silverlight在對戰WPF中勝出呢——這是因為我們客戶的運行環境的安裝問題。不必自己處理操作系統的不兼容和功能差異，Silverlight都能正常運行。并且，現在升級也輕而易舉，只用升級服務器，客戶端就能自動升級。當然，WPF更加強大，不過很多東西我們用不上。

　　在解釋了WPF和Silverlight的區別之后，Noyes總結道：

根本的決定因素是，如果你的客戶端應用程序主要是為了展現后端數據的前端界面的話——選擇Silverlight 4已經完全足夠。不過，如果你的客戶端應用程序需要更緊密地和客戶端機器集成，并且其他一些東西也要放在客戶端的話，使用SL4的信任提升OOB模式也可能勝任，但是這樣會給開發帶來更多的挑戰，也可能需要犧牲開發效率或功能來達成開發目標。你需要切切實實地做好前端需求分析，如果應用程序和客戶端機器資源有大量的交互的，WPF仍舊是最好的選擇，能讓你的開發工作事半功倍。

　　關于未來，一個微軟的資深產品經理Pete Brown，認為這兩種技術，WPF和Silverlight最終將合二為一：

我最近和微軟的Ian Ellison-Taylor交談過。Ian是一個直接向Scott Guthrie報告的總經理。在很多工作中，他的團隊要開發Silverlight和WPF兩者中的東西（以及RIA Services和其他很多東西）。我提到，我想在未來獲得一些小道消息，他說可以為我提供一些。所以，他和我談到了Silverlight和WPF合二為一的事情，并在隨后互發了一些關于這個話題的郵件。
未來，Silverlight和WPF很可能會成為一個基于同一份代碼的單一技術。畢竟，Silverlight是源自于所謂的WPF/E（E表示Everywhere），并以我們出乎意料的方式，棄用了這個丑陋的開發代號，而創造了一個美妙的產品名稱（Silverlight）。

　　在給出相關建議的時候，Brown的觀點和Noyes的也類似：“向右看，Silverlight是完成面向跨平臺RIA的最好方式。向左看，WPF是編寫用于Windows 7的托管代碼應用程序的最好方式。”
　　查看英文原文：WPF vs. Silverlight: Choosing the Best Technology for a Project
文章出處：飛諾網(www.diybl.com):http://www.diybl.com/course/4_webprogram/webjis/20100710/427560.html

轉載于:https://www.cnblogs.com/minide/articles/2234601.html

總結

以上是生活随笔為你收集整理的WPF对决Silverlight：为项目选择最佳技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。