.NET專家談Windows Presentation Foundation

iDotNetSpace發表於2008-01-22

[轉]

Windows Presentation Foundation是.NET 3.0中的一個令人感興趣的新開發工具。我們特邀WPF培訓師和作者Ian Griffiths為我們將介紹WPF、Silverlight和其它微軟產品。

你認為WPF最令人感興趣的是什麼?

對我來說,最感興趣的就是當我看到它所能夠完成的工作時的“最後”時刻。因為當使用Win32開發使用者介面時,有很多令人不滿意的地方,尤其是各個部分都不能很好地結合在一起。

你可以進行3D設計或開發視訊,但是在一個平臺上實現完成這兩件工作將是令人頭痛的事情,如果你想單獨開發使用者介面元件如按鈕和列表框並使它們能夠協作完成任務,那麼將所有元件組合起來將是一件不可能的事情。

WPF的優點

WPF將所有這些功能整合到一個平臺上完成,因此如果你想將視訊,圖形,3D和文字混合在一起,你將不再需要不同的平臺。這不像是擁有HTML、Flash、Win32和DirectX,它只是一個平臺。

你可以將這些整合到一起,但並不是說你可以將一個視訊放在一個按鈕上,實際上整合在一起並不是最令人感興趣的,而更令人感興趣的是它沒有任何限制。例如,我們在BBC上使用的視訊,通過資料繫結提供了大量資訊。

它可以在一個應用中使用,然後迅速轉向另一個視訊播放程式,現在我們可以將它們整合在一起使之像在一個應用中。沒有WPF根本不可能將它們融合在一起,正是WPF使得過去很難融合的東西結合在一起。

WPF中業務邏輯和使用者介面之間分離的優點是什麼?

坦白講,在所有使用者介面領域這都是很重要的。我的意思是如果你在考慮一些像Web應用之類的東西,他們已經作了好多年的這類事情。而且我敢保證我們都實現過所有邏輯都在HTML中實現的一些應用,完成這樣的工作真是令人恐怖。

因此,分離關注重點確實是一個很好的原則。因此,WPF只是學習了以前HTML世界領教過的教訓。但是,你可能會爭論我們曾經在Windows窗體中也有這樣的教訓,Windows窗體中有設計介面和程式碼介面它們有幾分的相似,但與WPF的最大區別是現在我們已經有了一個標記語言,即XAML代表使用者介面。

你可以獲得在使用者空間使用的但並不是開發人員使用的工具,然而,Windows 窗體實際上都是程式碼,因此當我們構建一個可用於設計使用者介面的工具時,你需要包含一個開發系統,實際上就是一個開發人員工具。

利用WPF進行開發的方法與之不同,你可以使用像微軟的Blend工具來構建XAML。同時還有畫圖包,Expression設計工具等。然後,你還可以獲得用於像Illustrator等這些能過直接插入XAML中的外掛,所以設計者可以使用這些工具來建立可以用於UI的標記。

這些事情在Windows窗體中是不可能做到的。Web其它開發工具作這些事情已有一段時間,我們有Dreamweaver和Frontpage等這些專用於標記的開發工具。WPF可以完成這些設計,同時具有執行於客戶端,良好的安全控制和硬體使用等優點。

如果用XAML進行開發,能夠在應用和網頁中都使用它嗎?

簡單的回答是不可以。這是很多人對WPF的一個誤解。主要是因為有一段時間微軟使用的宣傳口號:“最好的Web,最好的Windows”。人們就認為你開發的東西可以自動的在兩個地方執行。但實際上並非如此。

我們可以構建一個可在Web頁中執行的應用,我們將這些應用稱為XBAPS,XAML瀏覽器應用,但是這要求客戶端必須安裝WPF來執行這些應用,所以它們不會在蘋果OS X或Linux上執行,也不會在沒有安裝.NET 3.0框架的Windows 個人計算機上執行。

如果你安裝了.NET 3.0框架,它就會像一個WPF應用一樣可以在瀏覽器框架內執行,這樣的話,看起來就會沒有什麼不同,因為的確是一樣的。但是需要理解的是開發能夠實際工作的東西的空間是十分有限的,因為這要求客戶端安裝.NET 3.0。

還有Silverlight,這是現在名稱,以前稱為WPF/E。它實際上是移動了一點邊界,Silverlight的用意是解決大範圍的硬體問題,因此它可以執行在蘋果OS X系統上,可以是Power pc硬體也可以是Intel硬體,它還可以在IE之外執行,比如可以在firefox上執行。

但是這實際上不是使用WPF,而是使用XAML,因此,它和標記語言是同一家族的。不過它是XAML的一個相當有限的子集,你不能使用資料繫結,沒有佈局,沒有控制,只有一個受限版的事件模型。它是一個很小很小的子集,坦白地說,對開發人員來說,使WPF讓人真正感興趣的並不是Silverlight。

這是因為他們想把所有東西集合到一個很小的下載版中,他們想把翻譯,執行時,視訊回放都集合到一個只有一兩兆位元組的下載版中,而不是像你機器上的.NET 3.0有40或50兆位元組那麼大。因此,免得你必須為靈活性付出一些代價。

你可以開發一個Silverlight應用,但是構建一個即能作為普通應用執行同時又能作為一個WPF應用執行是不可能,現在還沒有能夠這樣做的方法。

或許將來會出現相應的工具,因為現在只是Silverlight發展的早期階段。但在你使用Silverlight的時候,只是使用Silverlight和瀏覽器,如果使用WPF和XBAPS,只要在客戶端有.NET,它們會和Siverlight看起來是一樣的。

你認為選擇Macintosh作為Silverlight的一個平臺,其理由是什麼?

我認為這在某種程度上宣示了該產品的跨平臺特性,它不只是用於Windows。通過演示它可以執行於Mac,可以執行於Firefox,可以執行於Safari,可以執行於所有其它不同處理器,這是在表明該產品與WPF不同的一種方式。

你不需要Windows特定平臺來執行它。至於為什麼他們首先做出這樣的宣告,是因為他們承認存在大量不使用Windows的人群,他們希望能夠接近這些人群。他們想說“看,你並沒有被限制在微軟的技術門外,只要你是執行Mac OSX的使用者。”

使用計算機的人群只是一少部分但是十分重要的一部分,尤其是在某些行業領域,計算機處於支配地位,即使只佔所有使用的個人計算機的很少的一部分。

如果你觀察一下微軟把像Expression套件等產品推向何處,你就會發現他們在逐漸集合這些產品以加強在那些領域的優勢。因此他們非常接近Macs,因為Macs在這些領域是強大的,否則的話微軟不會看重它。所以這只是微軟希望佔領真個市場的一個策略問題。

你如何看待XAML的將來,它可以用於WPF之外嗎?

XAML已在工作流框架Workflow Foundation中了, Workflow Foundation是.NET 3.0的一部分。雖然不是相同的編譯器,但是相同的語言,因為在開發時他們需要完成不同的工作,但使用的是相同的規範。因此,它是一個可在更廣的範圍內使用的語言。

XAML 的自然應用在何處還不是很清楚,因為XAML有一個特點,即雖然你可以使用它構建任意多個.NET物件樹,但是在大腦中用XAML設計好整個框架後再進行實際開發,效果往往會更好。所以你可以用XAML開發一個Windows窗體應用,但用WPF會更容易些,因為每個API特性都是按照我們設想的實現的。

利用Windows窗體不會實現這一點,因為這不是設計簡介的一部分。因此你可能需要利用XAML設計的API函式,這並不是利用現有的技術能夠實現的,除非你很幸運。更有趣的是這需要認真思考。

人們希望看到更多XAML的應用,他們會說:“是的,利用XAML可以很好的處理Windows Presentation和工作流,我們可以用它做其它的類似事情嗎?”但是我認為這需要一些時間,我的意思是這要看.NET3.0的普及應用需要多長時間,實質上是一個API設計問題,API設計是一個緩慢和複雜的過程。

從長遠觀點來看,我不知道XAML除了現在應用外,它還有走向何處。我們只有等待和觀察。基於XAML的新事物的出現並有明晰的發展方向的那一刻也是WPF專門工具出現的時刻,這些工具擴充套件了可以從微軟獲得資源。

我認為我們將會看到更多的繪圖工具支援,更多的於Bledn類似的第三方產品,例如,因為目前Blend是唯一可以實現相應功能的工具,它是面向WPF的,可用來構建WPF使用者介面,而沒有其他工具可以實現相同功能。當前所有支援XAML的產品都只有引入模式,你可以使Illustrator按照XAML輸入,但這是一個單向旅途。

Blend 可以很好的運用XAML,因此最令人感興趣的事情可能是看到更多使用XAML的工具,而且這些工具可以從本質上理解XAML。競爭產品或者像Blend所作的一樣,或者擴充套件應用空間,這些工具可以幫助你更好的使用XAML。

現在我不能確切知道這些工具都可以做些什麼,但是有廣泛的應用空間,因為XAML易於解析,就是XML,易於閱讀。所以,我期望看到人們創造的新東西。

最近,用於開發豐富網際網路應用的可用平臺有很多選項,這也是WPF的目標之一。為什麼開發人員選擇WPF而不是比如Apollo或XULRunner

當然,這取決於你的目標平臺的需要,因為有些應用領域你可以只使用Windows平臺就可以了,尤其是如果你正在構建一個豐富應用但又有一個有限應用範圍的應用時:比如如果你確切的知道那些人會執行該應用。

今年早些時候我做的最後一個專案就是這樣情況,我們要開發一個線上應用系統,但它只是一個邀請形式的應用,所以我們可以準確地知道那些地方會執行它。

這樣,我們就可以縮小平臺,你可以用圖形完成所有這些事情,但我們更接近,我們使用視訊做這些,我們可以進行高階定義。如果你的範圍太廣的話,所有這些事情可能都很難完成。

這是典型的最小公分母與縮小範圍的問題,你需要進行選擇是這一個還是另一個。因為WPF處於高階,它假定你是在執行.NET 3.0和相對最新的Windows的機器上工作。

因此,你已經準備好使用WPF。你已經決定將你限制在那個範圍內並開始利用它。然而,如果你著眼於範圍更廣的東西,你就會利用更多的機器,但同時你必須為此放棄一些東西,這裡面總有一個折中的問題。因此,WPF相對有趣只是因為它有些極端。

Windows表示層程式設計框架(Windows Presentation Foundation(WPF))是.NET3.0中最重要的開發環境,在這篇訪談中,Ian Griffiths將介紹WPF和Silverlight的相關內容,以及微軟在軟體框架上的競爭策略。

我們會不會看到這些軟體巨頭之間展開系統平臺戰爭和新的瀏覽器戰爭呢?

很明顯,所有的業界廠商都在積極籌備。Adobe不能錯過這樣的機會,他們的定位很明確——Flash,在這方面,Adobe比微軟具備先發優勢,也就是說他們已經佔據了先機。

儘管微軟推出了Silverlight,但是安裝了Silverlight的電腦數量遠遠比不上安裝了Flash的電腦,而且在未來的很長一段時間中還會繼續保持這樣的狀態。

當然,微軟想控制一切他們可以控制的事情,在作業系統領域,微軟就是這樣的策略,覆蓋的電腦越多就對他們越有利。

現在兩位軟體巨人正在爭奪同一領地,而且Google也正在加入競爭者的行列,儘管Google使用了AJAX技術,與微軟和Adobe的方法不同,但是他們的基本想法是相同的。

不過這幾家公司的產品釋出模式和商業模式是不同的,所以現在成敗還很難講,他們都很強大,而且都在試圖通過各種途徑進入使用者的桌面。現在是一個很有意思的競爭階段,儘管目前無法斷定這些產品將會走向何方,但可以肯定的是未來的競爭將會非常激烈。

微軟控制了作業系統領域,您覺得這會給他們帶來網路瀏覽器競爭上的領先地位麼?

我覺得這是一個很大的優勢,但是微軟也受到很多限制,不可能沒有限制地使用這些優勢,否則又會有法律上的麻煩了。

在美國和歐盟的法律體系上,已經證明了只要有一點點機會,那麼擊敗微軟將是一件很容易的事情。比如,微軟如果將Silverlight當作軟體升級來發布,這種做法是不允許的,微軟對這樣的界限很明確,因此必須要很小心地來利用手中的這些優勢,必須保證不會被視為藉助壟斷地位來捆綁產品。

我想這也是恰恰是Google和Adobe的優勢所在,Google佔據了統治地位,但是不是壟斷者,因為改變搜尋引擎是一件很容易的事情,其實Google是一個很經典的例子,最初出現的時候並不出名,但是最終擊敗了所有的對手。

Adobe的地位與Google相當,因為沒有人認為Adobe是壟斷者,我覺得Flash是一個很有意思的平臺,如果有人針對Flash展開反壟斷的法律訴訟,會發生什麼樣的事情呢?也許真的有這樣的官司,但是我並不是律師,對於這些法律上的事情也不是很清楚,但如果我是Adobe的話,我是不會因為利用壟斷地位侵犯競爭對手的事情擔心的。

您認為未來的趨勢是從桌面軟體向網際網路軟體轉移還是從網際網路軟體向桌面軟體轉移?

這是一個很有意思的問題,有些人認為基於網際網路的應用軟體一定會贏,只是時間的問題,因為這些軟體可以提供桌面軟體所提供的一切功能。

Paul Graham是一位著名的風險投資家,最近他在一篇文章中表示微軟已經死了。當然這不是指財務上的問題,微軟的財力可以支撐很長的時間,就像當年的IBM一樣,但是他認為從技術角度上講,Web的成功已經說明了這個問題。

當然,他從Web2.0的投資中獲得了巨大的成功。但事實上,對這個問題下定論是很困難的,因為我的背景是胖客戶端的開發、用於媒體廣播的數字電視,因此我對視覺效果的質量非常在意。

所以對於我所要求的外觀質量和使用者的互動性質量而言,現在的基於Web的軟體都很垃圾,從可用性的角度來說,它們幾乎無法使用。

比如在Paul Graham的文章中提到了桌面應用軟體正在被基於網際網路的應用軟體趕超,甚至連Photoshop也包含在內,我想…“這是真的麼?”於是我開啟線上照片編輯的連結,準備試試看到底功能如何。

首先,我從數位相機中把照片上傳到網站上,和我的數位相機附帶的Photoshop Elements 軟體相比,線上應用軟體並沒有任何的優異之處。

好的,接下來,我能做什麼事情呢?我可以剪裁、縮放照片並使用一鍵改善功能。但是對於我來說,這並不是一個可以替代Photoshop的軟體,比如,我需要清除鏡頭上的手印,這是我經常要做的一件事情;而且線上軟體也沒有提供控制照片的亮度和對比度的功能。

對於這些基於網際網路的線上軟體而言,最大的問題是它們極其緩慢的速度,這是因為大量的資料操作受到網路速度的瓶頸限制。

也許十年之後我們會擁有200兆的網路接入速度,那麼速度就不再成為問題,但是對目前而言,這一點是線上軟體最大的弱點。

另外的一個問題就是延遲,頻寬問題可以慢慢改善,但是延遲卻永遠都無法解決,您不能將悉尼和倫敦移動到一起,因此延遲總會存在,線上軟體需要對延遲制定相應的規則來進行控制。

剛才提到過我的評審角度是要求完美,對於媒體廣播而言,可能有數以百萬計的觀眾,你必須認真對待,否則就不要在這個行業中工作。

也許您覺得對於桌面軟體而言,並不需要如此的完美,那麼這個問題就變成“對於大多數人而言,基於網際網路的線上軟體是不是已經足夠好了呢?桌面軟體所具備的優勢是不是對除了我這樣的極客之外的使用者都不重要呢?”我覺得這個問題的正確答案至少價值十億美元。

對於有些領域的應用軟體而言,他們已經做到了這一點,我的一些朋友就喜歡使用Gmail而放棄了Outlook。

但這對我並不適用,因為我有很多時間都在世界各地飛來飛去,但是Gmail在飛機上無法使用。如果您的網路連線並不穩定,一會兒連得上,一會兒連線不上網路,那麼網路就無法提供您需要的資訊了。

您需要在客戶端儲存一定的資訊來保證您的正常工作,我的個人資料有1G,其中一半是我的電子郵件,我需要經常使用其中的資訊並保持同步。我的建議是,除非您具備永久線上的網路連線,否則完全依賴網路空間並不是一個很好的主意。

當然,對於重要資料的備份確實很重要,在網上瀏覽電子郵件也是非常有意義的,這樣我就不用時刻擔心我的膝上型電腦裡的那塊脆弱的2.5英寸硬碟會壞掉。

因為電子郵件都儲存在本地電腦之外,這樣我就可以格式化硬碟,重新安裝Windows作業系統,然後我的郵件又會重新出現,這的確很棒。

但這並不是網路與桌面應用軟體的區別,不過這個電子郵件的例子說明了一個重要問題:如果將桌面軟體和線上軟體的優勢結合起來就可以充分發揮出兩者的強大功能。

就我個人而言,線上軟體有太多的缺點,而且根本性的技術問題很難克服,除非我們解決了網路速度的問題。

但現在其實有不少可以解決的問題卻並沒有引起注意,畢竟頻寬的問題是一個相對緩慢的發展程式,尤其是我們要求每個人都擁有視訊播放的頻寬,那麼下一次網路升級的驅動力是什麼呢?除非有特殊的事情帶來新的投資,並且有足夠的理由相信新的網路應用軟體確實需要10M的頻寬。

未來如何,現在還很難預言,這類問題從來都很難預言,我個人認為線上軟體現在還很不成熟,因為我對這些無法實現預期功能的東西很反感,即使我發現自己在這個問題上處於少數派,我也不會感到很驚訝。

您最近出席了很多軟體開發者的培訓,您被問到最多的問題是什麼?

我應該使用WPF麼?我的意思是很多參加培訓的人都很關心現在是不是轉換的時機,因為在沒有使用過一項技術之前很難做出決定。

大家還非常關心微軟對於Silverlight的策略問題,開發者希望構建具備整個網站功能的單個網頁,同時這個網頁可以像多媒體桌面軟體一樣華麗。這樣的事情還沒有發生,而且我還沒有看到有任何的方法可以讓這樣的事情成為現實,不過可以肯定的是對這種事情的需求很高。

對於微軟而言,他們會繼續向這個領域發展,因為他們知道人們需要的是什麼,只有當他們越走越近的時候,這些事情才有可能成為現實。這個領域現在吸引了很多人的參與,網路應用與胖客戶軟體系統會越走越近,不過在一種混亂的環境下,大家都處在一種迷失的狀態。

那麼現在是轉換的時機麼?

這完全取決於您現在做的事情是什麼。如果您正在構建的應用軟體將會從新技術中獲益,而且所需要的功能離不開WPF的支援,那麼答案是“是”。

如果您正在編寫的是商業資料錄入軟體,那麼答案是“否”。因為到目前為止,開發工具的支援還沒有完成,而且微軟也沒有正式釋出官方的開發工具,一切都只是XAML——您需要手動輸入這些標記或者使用尚未正式釋出的軟體工具。

不過混合了這些技術的開發工具很快就要釋出了,短則幾周,長則幾個月就會發布,我感覺這些預覽版的功能已經很全面了,正式版的狀態會更好,這一開發工具是完全面向開發者的,用起來很順手,比起手動輸入XAML來要便捷多了。

Visual Studio也會有更新的發展,最近釋出了Orcas的beta1版,這一版本VS將是正式支援WPF的第一個版本,我個人並不認為它會提供豐富的開發設計體驗,因為它只是為了儘快為WPF的開發者提供一些有用的東西,而不必等待好幾年才推出新版本。

我想我們會看到微軟更堅實的腳步,以後會提供比現在更好的東西,不過更大的突破至少要等到下一個釋出版本了。

如果您已經在使用Windows Form了,並且正在開發的過程中,那麼我想現在並不是轉換的時機,因為您並不需要WPF提供的任何新特色,當然,資料繫結可能是個例外。

WPF的資料繫結比Windows Form要好很多,很多人僅僅因為這個原因就轉換到了WPF,還有一些開發者使用了混合模式,軟體主體使用Windows Form而在中間層使用了一些WPF的資料繫結。

這可能是個艱難的決定,因為您需要找到願意使用兩種平臺的開發者,這可能會增加您的成本,但是這種方法確實很有效。

比較麻煩的問題是那些構建具有複雜的圖形功能的軟體,他們可能從WPF中獲益,但是在Windows Form也可以實現同樣的功能。

我覺得這取決於您目前處在產品的生命週期的什麼位置,如果您的產品在市場上已經存在很多年了,那麼現在並不是轉換的好時機,您需要仔細考慮產品轉換的策略;如果您正在考慮新產品或者重大的產品升級,那麼使用WPF是個不錯的主意。

如果您正在考慮使用.NET進行開發,那麼這又是個複雜的選擇,如果您選擇了WPF,您需要注意的是現在可供使用的開發工具還沒有完成。

但是如果您正在策劃未來五年到十年的產品策略,您願意將新產品寄託在Windows Form上麼?很多公司都認為現在並不是使用Windows Form進行新的開發專案的時機。

儘管Windows Form可以非常好地完成既定的任務,但是很多新技術已經展現出曙光,在MFC上曾經發生的事情,現在將會在Windows Form上重演。

因此,對我而言,使用Windows Form進行全新的開發看上去是一件風險很大的事情,這樣做會把您套牢在過時的系統平臺上。很多參加培訓的人和業界公司都得出了這樣的結論。

同樣,我們知道現在進行轉換還為時過早,但是我們需要進行轉換因為WPF具備超出Windows Form的新功能。儘管這是一個艱難的決定,但是WPF提供的新特色遠遠超出Windows Form,在未來的很多年中,WPF會日益完善,功能日益強大,但是目前是這一轉換的痛苦的磨合期。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/12639172/viewspace-157088/,如需轉載,請註明出處,否則將追究法律責任。

相關文章