.net wpf全名 在創建新的GUI時,WPF是Windows Forms的首選嗎?



wpf全名 (24)

大多數程序員常常使用Windows窗體的大多數限制和技巧。 但是由於.NET 3.0還提供了WPF可用的Windows Presentation Foundation。 據說,您可以使“性感應用程序”更容易使用,並使用.NET 3.5 SP1,它的執行速度得到了很好的提升。

但另一方面,很多事情都與WPF有所不同。 我不會說這更困難,但你必須從頭開始學習“一切”。

我的問題:當您必須創建一個新的GUI並且項目沒有時間壓力時,是否值得花費額外的時間?


Answer #1

WPF的優點在於,通過自定義控件和動畫創建漂亮的GUI是比較容易的。 WPF還有助於進一步排列表示和邏輯層。 如果您有設計師,您可以將95%的這項工作納入非編程人員,並允許編程人員處理邏輯。 缺點是表達式混合的軟件成本,以及缺少任何Visual Studio代碼分析工具,因為它們傾向於在嘗試渲染XAML的框架調用中被捕獲。 我相信有其他人,但這是我們真正看到的唯一的兩個。

主要考慮的是如果您希望要求您的客戶必須安裝.NET 3.0或更好的.NET 3.5 SP1。 你會得到一些消息反饋


Answer #2

是否有任何令人信服的理由使用WPF

絕對! WPF絕對不可思議! 對於幾乎任何項目來說,這將是一個主要的好處,因為它具有Windows Forms缺少的許多功能和功能。

對於商業應用,最大的勝利將是:

  • 夢幻般的數據綁定和模板化最大的區別。 一旦體面的數據模型到位,只需要點擊幾下創建一個數據模板,並使用Expression Blend來精確地配置你的對象將如何使用拖放。 並且綁定到顏色或形狀的東西是微不足道的。
  • 屏幕佈局非常靈活。 WPF中的所有內容不僅可以順利地調整到容器尺寸和形狀的變化,而且可以簡單地擴大和旋轉物品,甚至延伸到包含的框架之外。
  • 普通對象可以任何您喜歡的方式呈現,可以輕鬆地在不同的屏幕中顯示不同的演示文稿,可以共享演示文稿,並且可以使其演示文稿適應數據值的更改。
  • 如果需要打印,渲染到打印機是微不足道的。 正確配置,WPF使Crystal ReportsSQL Server Reporting Services (SSRS)看起來像一個孩子的玩具。
  • 您的用戶界面的外觀和感覺會更加動態,包括不錯的功能,例如將鼠標懸停在其上時的動畫效果。

對於公用事業和遊戲,其他優勢來到最前列:

  • 您可以輕鬆地向應用程序添加形狀,線條和任意圖形,而無需使用外部編輯器。 這些的每個組件都可以被數據綁定和動畫化,或由代碼控制。 在Windows窗體中,您通常只需要導入位圖並將其原樣使用,除非您想要進行大量工作。
  • 動畫很酷! 只要你不過分,用戶將會印象深刻。 他們也可以幫助人們看到正在發生的事情,減少危害的需要。 例如,拖動對象時,您可以對目標進行動畫處理,以顯示如果您刪除它將會發生什麼。
  • 顏色,漸變填充,畫筆,花式字體,任何對象的旋轉,瓷磚刷等。您想要的圖形都是您的要求。
  • 令人難以置信的定制。 我需要為一個應用程序繪製鐵軌,所以我可以給他們搭火車。 幾個小時後,我可以使用Bézier曲線在屏幕上的任何地方繪製鐵軌,並自動加入並切換。

底線是,您可以在Windows窗體中構建的任何顯著大小的GUI可以以三分之一(或更少)的方式構建在WPF中,並且看起來更好。

WPF需要更多資源(特別是RAM)

與Windows Forms相比,您需要付出代價,但這是一個小的價格。

  • RAM可以上下移動,具體取決於您的實現。 WPF更有效地存儲數據,因此單個對象更小,但WPF中的對象往往比Windows窗體中的更多,這樣可以平衡出來。
  • CPU將與Windows窗體相比上升。 根據我的經驗,屏幕上實際更新的WPF對像大約是Windows窗體渲染的兩倍。 如果您的應用程序大部分時間更新屏幕,WPF可能不適合您。 但是在這種情況下,您可能還沒有使用Windows Forms:最嚴肅的遊戲直接寫入DirectX
  • WPF的磁盤使用率會稍微降低一點,因為它比Windows Forms少得多的代碼。 數據當然會是相同的大小。

關於CPU使用的另一個注意事項:WPF中的動畫和轉換(運動,翻譯等)實際上比Windows窗體中更有效,因為它保留了模式存儲。 這是最初獲得的對像在那裡較慢。

維護開銷

當涉及到維護時,WPF是Windows窗體的巨大勝利。 由於一切都是以1/5以前的代碼完成的,所以保持的是1/5。 加上所有的樣板材料都不見了,所以你可以專注於實際工作的代碼。

XAML的優點

XAML是WPF的核心。 雖然WPF可以在不使用XAML的情況下使用,但XAML使其非常易於使用。 XAML具有HTML的輕鬆指定用戶界面的功能,但內置的標籤功能更強大,您可以輕鬆地定義自己的界面。 (事實上,這是正常的)。

XAML的一些具體優點:

  • 您的整個UI在一個文本文件中定義,易於閱讀和操作,無論是用戶還是工具
  • 標記擴展允許以明確和簡單的方式指定綁定
  • 類型轉換器允許容易地指定複雜類型的屬性。 例如,您可以說Brush =“Green”,或者您可以指定具有三個停止點的徑向漸變畫筆。
  • 您可以創建自己的元素
  • 您可以輕鬆地利用WPF強大的“附加屬性”

其他見解

我夢想著像WPF這樣的東西多年。 許多人已經實現了這個功能的一部分,但是將其全部放在一個地方,價格($ 0)是驚人的。

WPF是從Windows窗體的一個巨大的範例轉變,並將採取一些習慣,但花時間學習它將支付多少。

WPF甚至五年之後仍然有幾滴疣,但一旦體驗到WPF,它的力量就會徹底打擊你。 如果有人試圖將你拖回Windows窗體,你只會踢和尖叫。

提示: - 獲得Expression Blend的開發副本 - 偶爾手動編輯XAML - 首先看起來很奇怪,不要放棄


Answer #3

作為一個附加獎金,Silverlight是基於WPF,從開始,讓你知道如何與另一個工作。 如果事情繼續以網絡為基礎,將先前的知識(和現有代碼庫)輕鬆轉移到瀏覽器(或Windows Live Mesh)可能有助於為您的軟件提供額外的生命。


Answer #4

WPF具有很多優點,如精湛的數據綁定功能,關注點分離,設計和邏輯分離等...

作為開發人員,我喜歡使用XAML定義我的UI,而不是綁定到Windows窗體設計器,我覺得很好,知道我可以指望另一位設計師使我的應用程序看起來不錯。

個人而言,我不關心Windows的舊版本不受支持,但WPF的一個大問題是Mono( http://www.mono-project.com )不支持(目前/以前)),因此WPF應用程序不能在Mac OS或Linux上運行。 (Altough Silverlight應用程序將)。

如果你有時間和資源來投資學習WPF,做吧! 即使您要編寫Silverlight應用程序來支持多個操作系統。

如果您需要桌面應用程序在多個操作系統的SWF上運行。


Answer #5

那麼一個答案是“當你必須支持1.1或2.0”,因為WPF是.NET 3.0的一部分。 對於WPF有已知的操作系統限制,並且有一個明顯的技術問題:如果您有一個知道winforms的開發人員團隊,那麼使用 winforms可以更容易地生成強大的代碼。 但是,如果您正在編寫很多UI代碼,那麼在某些時候可能值得開始接收WPF。

WPF也與Silverlight有很多共同之處,因此具有可轉讓的優勢。


Answer #6

這兩種技術都有其利弊。 在具有“經典”UI的大型應用程序中,我將使用Windows窗體。 在需要豐富的用戶界面(皮膚,動畫,改變用戶界面)的應用程序中,我會選擇WPF。 請檢查文章WPF與Windows窗體比較WPF和Windows窗體。


Answer #7

有許多不同之處。我們喜歡WPF為:

  1. 編程的聲明樣式。
  2. 動畫和狀態轉換
  3. Expression Blend將是一個偉大的工具
  4. 好作風的支持。

但是,我們堅持與Windows窗體,因為:

  1. 它需要一個開發額外的時間來學習WPF時,他們已經知道Windows窗體。
  2. WPF將無法在Windows 2000或更低的運行。

Answer #8

來自馬克的早期帖子的引用:

  • 在Windows Forms中,您可以設計用戶界面,然後編寫代碼來驅動該用戶界面,該界面通常還包括驅動數據對象的代碼。
  • 在WPF中,您投資於驅動數據對象的業務層,然後設計一個監聽數據對象的接口。

我會認為這是更多的設計選擇,而不是你是否使用Windows窗體或WPF。 然而,我可以理解,某些技術可能更適合於特定的方法。


Answer #9

在過去3年半的時間裡,我一直在做Windows窗體開發(在兩家公司)。 這兩種應用都被廣泛使用,最終導致了GDI問題。 大型Windows窗體應用程序最終將用盡GDI資源 - 導致最終用戶必須重新啟動。


Answer #10

如果您只關心支持Windows,並且不介意學習的時間,請使用WPF。 它的快速,靈活,易於復原,並具有很好的工具來處理它。


Answer #11

除了UI設計的靈活性外,WPF還有一些技術優勢:

1.)WPF不依賴於GDI對象。 那麼,我認為它使用2個GDI對像作為窗口本身的實例,但實際上沒有。 我在一定程度上參與了一個非常大的內部Windows窗體應用程序。 我們辦公室的人有時會同時運行3或4個實例。 問題是它們經常遇到Windows 2000,XP和Vista固有的10,000 GDI對象限制。 當這種情況發生時,整個操作系統變得無響應,您將開始看到視覺工件。 清除它的唯一方法是關閉應用程序。

2.)WPF利用GPU。 WPF將某些UI處理卸載到GPU的能力是輝煌的。 我只期望它的這個方面隨著時間的推移變得更好。 作為一個以前的OpenGL編程愛好者,我可以欣賞GPU的力量。 我的意思是說,我的$ 100視頻卡有112個核心,每個1.5GHz的速度運行(並不是任何方式的頂部)。 那種並行處理能力可以使任何四核CPU感到恥辱。

但是,WPF還是很新的。 它不會在Windows 2000上運行。實際上,一個WPF應用程序在新的重新啟動後啟動速度很慢。 我在我的博客上談到所有這一切: http : //blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html


Answer #12

只有你沒有WPF的專長,你不想投資它:)


Answer #13

WPF有一個非常陡峭的學習曲線,我建議您首先獲得明顯的書籍( Adam NathanSells / GriffithsChris Anderson )和博客( Josh Smith等)。 只要做好準備,並確保您的項目讓您有機會學習WPF。

除了學習技術,花一些時間學習用於構建WPF應用程序的模式。 模型視圖ViewModel (MVVM)似乎已經獲得了很大的接受。

就個人而言,我認為WPF是值得的,但要預先警告。 另請注意,您有效地將您的用戶限制在Windows XP SP2 +和Windows Vista。 我們做出了這個決定,但你可能會有一些不同的要求。


Answer #14

我認為值得學習WPF。 一旦你加快速度,設計工作在你的表單上更容易IMHO。 我不用擔心“性感”的東西。 大多數這只是一個時尚。 您可以在WPF中快速方便地創建“正常”Winforms樣式的應用程序。

整個概念使IMO設計更加簡單。


Answer #15

我不同意這裡的一些答案。 WPF非常適合業務線 (LOB)應用程序。 (青蛙設計LOB客戶端是最好的例子)。 除了所有可能性使您的UI成為眼睛糖果(這在業務應用程序中不是必需的),WPF為您提供了更多。

數據綁定和模板功能只是優於Windows窗體。 它還提供了一種更好的分離代碼和演示文稿的方法。 我們已經成功地將WPF用於2個LOB應用程序,團隊中不超過2-3個開發人員。

您將面臨的最大問題可能是WPF(與Windows Forms相比)的陡峭學習曲線,這將使開發人員不會使用WPF來降低開發速度。


Answer #16

我現在在使用WPF已經成為我的客戶的核心系統七個月了,我想和大家分享一些關於學習和使用WPF作為業務演示平台的經驗的一些想法。

一般來說,我上面提出的評論仍然存在... WPF的設計時間支持還沒有在這裡。 如果您急於將富客戶端應用程序從門外卸載,請使用Windows窗體。 期。 微軟並不急於停止GDI / Windows Forms平台,所以您可以依靠對未來公平的時間的良好支持。

WPF是不容易掌握的 ,但是不應該將您的下載關於是否投入時間和精力用於學習WPF的地方。 儘管目前缺乏成熟度,WPF建立在一些有用的現代概念之上。

例如,在WPF中,您對具有良好驗證邏輯的精心編寫的業務對象的投資是一項堅實的投資。 與Windows窗體不同,WPF的數據綁定具有允許接口控件對無效用戶輸入做出反應的功能, 而無需編寫GUI代碼來檢測這些錯誤。 這是有價值的

WPF的造型和模板功能也被證明是有價值的。 儘管人們常常誤以為造型和模板的唯一用途是創建屏幕上的眼睛,但事實是,這些功能大大簡化了用戶界面的編碼,從而提供了豐富的反饋,如按鈕,可以基於底層業務邏輯層的狀態,或根據光標下的對象狀態等智能地找到文本的工具提示等。

這些都為“無所作為”的業務應用程序增加了非常有價值的功能,只是因為它們使界面與底層數據保持一致。

簡而言之:

  • 在Windows Forms中,您可以設計用戶界面,然後編寫代碼來驅動該用戶界面,該界面通常還包括驅動數據對象的代碼。
  • 在WPF中,您投資於驅動數據對象的業務層,然後設計一個監聽數據對象的接口。

這是一個看似微妙的區別,但是它對您重新使用代碼的能力造成了巨大的改變,這就產生了一個問題:“Windows窗體與WPF問題實際上是一個投資決策嗎?”

(這似乎已經成為我最喜歡的線程。)


Answer #17

經過三個月的嘗試,在WPF上推出了一個業務線 (LOB)應用程序,我達到了一個考慮回到Windows窗體為我的項目,並在研究其他人的意見,遇到這個線程的一點...

是的,WPF是一項輝煌的技術,它具有的優勢遠遠超出了眼光,但模板和綁定功能是很好的例子。 整個對像模型提供更多的靈活性和更廣泛的可能性。 然而,這並不意味著它成為未來LOB應用程序的defacto平台。

WPF在將GUI與業務邏輯分離方面解決的“問題”不是Windows窗體中不能輕易解決的問題,只需從正確的架構和思路開始。 即使是WPF的對象路徑綁定功能,也可以在Windows Forms中復制一些非常簡單的助手類。 WPF的數據模板功能是非常好的,但是再一次,當您絕對不知道您將要在任何給定的部分中代表什麼對象時,它們在Windows Forms中無法模擬,屏幕。

Windows Forms在未來的比賽中就是在成熟期。 你不能在谷歌上擺動一隻死貓,而不會碰到一些有人為你解決Windows窗體問題的博客。 另一方面,WPF具有相對較少的學習資源,更少的定制控件可用,並且沒有解決其許多問題。

在WPF與Windows Forms決策的高峰期,必須成為開發環境的成熟度。 Windows Forms編輯器光滑,響應和直觀。 有關錯誤的反饋立即得到您,解決方案通常是顯而易見的,Windows窗體中的編譯 - >調試 - >編輯週期非常快。

另一方面,WPF應用程序具有相對可怕的設計時間支持,設計視圖在第一次遇到錯誤時已經準備好了,在設計人員願意踢之後,通常需要修復後的項目構建再次。 考慮到廣泛的情況,它根本不起作用,或產生完全不直觀的結果,拖動組件從工具箱中拖放也可能不受支持。 儘管WpfToolkit有希望,但仍然沒有可用的WPF DataGrid可以產生任何一種共鳴性能或設計時間友好性。

調試WPF應用程序有點像舊的 ASP.NET調試範例...點擊F5 - >等待 - >啟動 - >錯誤 - >停止 - >修復 - >點擊F5 - >等待 - >啟動 - >錯誤 - >呻吟- >停止 - >修復 - >點擊F5 ....您的程序正在運行的所有XAML被鎖定,跟踪XAML的具體問題往往很乏味。

底線簡單地說,Windows窗體的開發工具將會在WPF應用程序的一小部分時間內擺脫前端... 特別是如果您正在創建主細節網格或電子表格像界面,大多數LOB都有。 使用Windows窗體,您可以從已經完成的90%的工作開始。

我是WPF架構的巨大粉絲。 我只是希望設計時工具集不像一個pre-alpha調試版本。

編輯:此答案發布關於.NET 3.5 + Visual Studio 2008,但.NET 4.0與Visual Studio 2010隨附一個WPF數據網格。 雖然對新的WPF開發經驗進行了許多改進,但我的答案保持不變,我想補充以下建議:

如果您急於進行RAD開發,請使用Windows窗體。 如果您希望生成一個良好的架構,可維護,可擴展的資源,多用戶線上業務應用程序,請考慮使用ASP.NET MVC + HTML 5 + jQuery ...我使用這些技術的項目已經導致更好的結果,更快,為我的客戶。 MVC提供所有與WPF相同的模板,而jQuery可以進行動畫和復雜的交互。 更重要的是,ASP.NET MVC + jQuery解決方案不要求您的終端用戶擁有體面的圖形硬件的現代桌面。


Answer #18

WPF使您能夠做一些令人驚奇的事情,我喜歡它...但是,當開發人員問我是否認為他們應該轉向新技術時,我總是有義務符合我的建議。

您的開發人員願意(最好是EAGER)花時間花時間學習使用WPF嗎? 我從來沒有想過對MFC或Windows Forms,甚至是非託管DirectX說這個,但你可能不希望一個團隊試圖在正常的開發過程中“拾起”WPF。 循環運送產品!

至少有一兩個開發人員有一些設計感覺,並且做最終設計權限的人對開發問題有一個正確的理解,所以你可以利用WPF功能來創造一個實際上更好的東西,而不是只有更多的“豐富多彩”以無償動畫為特色

您的目標客戶群有一部分運行在可能不支持您計劃的功能的集成顯卡芯片組上,還是仍在運行Windows 2000,這將徹底消除它們的消費者? 有些人還會詢問您的客戶是否真的關心增強的視覺效果,但是在90年代初,通過內部公司“我們的業務客戶不關心顏色和圖片”的辯論,我知道您的競爭對手精心設計的解決方案會讓他們關心,真正的問題是條件是否正確,讓你能夠提供一些讓他們現在關心的東西。

項目是否涉及到開發,至少在表示層​​,避免額外的複雜性試圖鉤住不兼容的遺產腳手架(Interop與Win Forms不是無縫的)?

您的經理能否接受(或分心注意)四至六個月的開發人員生產力的重大跌幅?

這最後一個問題是由於我喜歡將WPF的“FizzBin”性質視為“FizzBin”性質,有十種不同的方式來實現任何任務,也沒有明顯的理由傾向於採用另一種方​​法,而且很少有指導可以幫助您選擇。 您所做的任何選擇的缺點不僅在項目的後期變得清晰,而且您幾乎可以保證讓您的項目中的每個開發人員都採用不同的方法,導致嚴重的維護頭痛。 最令人沮喪的是,您一直在努力學習框架,這是不一致的。

您可以在我的博客的條目中找到更多更深入的WPF相關信息:

http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx


Answer #19

如果界面設計對您很重要,請考慮WPF,因為WPF可以提供更好的UI體驗。 但是Windows窗體已經在多方面發展,所以它被證明是有效的,你可以找到許多精通這個平台的程序員。

還可移植性可能是一個問題,WPF僅適用於Windows XP SP2及更高版本。

此外,WPF具有陡峭的學習曲線,這意味著在不具有特定WPF體驗的情況下交付優質產品並不容易。


Answer #20

WPF更容易將表單設計工作交給實際的設計師,而不是設計師服裝的開發人員。 如果這是你想要做的事情,WPF就是你的答案。 如果經典的Windows風格的按鈕很好,那麼Windows窗體可能就是要走的路。

(多個答案表明你應該使用WPF,如果界面設計是“對你很重要”,但這很模糊,界面設計總是“重要”)。


Answer #21

我們正在從Windows窗體重寫我們在WPF中的應用程序。 是的,有一個陡峭的學習曲線,你必須“重新學習”一些事情,但它是值得的。 結合WCF,我們發現我們的代碼編寫速度比以往任何時候都更少,更快,更強大。

堅持一段時間,閱讀亞當·內森的書 ,並查看不斷增長的第三方控製圖書館,如TelerikComponentOne 。 一個消極的,在我看來,設計工具, 表達式混合 ,使用非常尷尬。 最新版本仍然處於測試階段,但是對於那些使用Visual Studio的人來說,這幾年並不適合。 是的,它主要是為了設計師,但有些事情你在Visual Studio中無法做到。



Answer #23

斯科特正在抱怨Expression Blend ,他對開發者來說是沒有意義的。 我對Expression Blend的第一反應就是這樣。 然而,現在我把它看作是一個非常寶貴的工具,但這真的取決於你是什麼類型的開發者。

我是必須執行Integrator角色的用戶界面開發人員,最終我發現Expression Blend無法創建樣式,並以所見即所得的方式控制模板。 我幾乎總是在同一個項目中同時運行Expression Blend和Visual Studio。

我也認為,在Expression Blend中玩耍,看看XAML會吐出來,是學習WPF API的一個很好的方法...很像在Windows窗體中使用設計器並檢查它吐出來的C#代碼是有幫助的在學習如何使用您正在設計的任何東西。

Expression Blend是有幫助的。 只要試一試,特別是如果您正在處理應用程序的視覺效果。


Answer #24

WPF中的文本呈現有一個已知的問題。 許多用戶報告說,大量使用抗鋸齒和像素混合使用的模糊文本。 在某些情況下,這是一個很大的破壞者,據我所知,微軟已經在某種程度上承認了這一點。





.net-3.0