2009-10-29 72 views
4

似乎這兩種已經相似的技術正在融合成一項技術。 Silverlight工具箱中有更多類似WPF的控件,WPF現在有Silverlight的VisaulStateManager。在這一點上,可以說Silverlight在可用主題數量方面甚至超過了WPF。WPF和Silverlight是否碰撞?

直到這兩種技術成爲一體後才能持續多久?直到富客戶端應用程序和豐富的瀏覽器應用程序之間的差異是一個簡單的編譯時設置多長時間?

編輯

讓我澄清我的問題。我意識到,出於安全原因,任何瀏覽器應用程序都需要在「沙箱」中運行,並且我也明白要保持瀏覽器插件儘可能小,但兩種技術之間可能會有一些細微的差別,可能會被解決而不會影響這些目標。例如,UI控件和主題之間可能會有更多的重疊。今天,您不能僅僅在WPF應用程序中使用Silverlight主題,但微軟能夠實現這一點有多大的飛躍?

+3

我們該如何回答這個問題? – 2009-10-29 22:16:01

+2

儘管我同意這裏提出的觀點,並且認爲Silverlight將包含WPF,但這不是真正的問題,任何人都無法回答(除非他們當然是微軟員工) – ChrisF 2009-10-29 22:19:06

+0

@ChrisF And他們可能會遇到麻煩。 – 2009-10-29 22:21:38

回答

7

我不認爲他們會合併成一個產品。微軟故意留下很多Silverlight以減少其佔地面積。然後,Silverlight在瀏覽器中運行時必須遵守大量的安全問題。當然,他們已經設計了它,因此它可以在PC或Mac上運行(不幸的是,.NET Framework不能這麼說)。

雖然我很高興看到WPF和Silverlight共享的資源。他們從一開始就應該是相似的。因此,將Silverlight項目移植到WPF中相對比較容易。另一方面,從WPF到Silverlight並不簡單,因爲WPF一直有更多的功能,但這只是野獸的本質。

更新:

所以你修改後的問題很有趣。如果微軟能夠讓你基本上改變一個開關來改變你的應用在類似Silverlight的功能和WPF之間的行爲,那將是很酷的。他們將面臨很多挑戰,不僅是安全性,而且還有一些輕量級Silverlight控件與功能豐富的WPF控件的基本行爲。這些差異可能會使開發人員的事情進一步複雜化。

例如,在WPF中,在文本框中有一個內置的多重撤消系統。在Silverlight中沒有這樣的事情,所以我實際上必須自己寫。爲了讓開發人員能夠解決這些問題,他們必須對應用程序進行大量功能檢查。

說了這麼多,我想你所描述的編譯時開關可能是可行的。但我仍然認爲微軟不太可能在短期內創造這種能力。

2

XAML和數據綁定可能在兩個
之間變得更近,但框架的其餘部分可能永遠不會相同。
曾經,您無法使用Silverlight自動化Office應用程序。
而且這可能永遠不會發生,除非MS決定在插件和.NET Framework之間打開某種類型的網橋

安全性,一致性和卓越的用戶界面是Silverlight的主要推動力。
如果你可以在Windows中做一些你不能在Mac上做的事情,那麼
一致性會丟失。

1

Silverlight安裝爲特定操作系統構建了自己的庫。我們作爲開發人員使用微軟提供的可以在這些系統上運行的軟件。 WPF完全信任使用特定窗口API調用的Windows操作系統。所以,我認爲他們永遠不會合並。

0

是的,我們將看到WPF和Silverlight變得越來越相似,如果敏銳地將合併?也許這不是不可能的,但我們將看到的僅僅是你說他們會更相似。所以在將來你不會實現WPF或者Silverlight,你只需要實現XMAL。

+2

你甚至知道這兩種技術是如何工作的嗎? – 2009-10-29 22:27:18

+0

我的意思是XMAL將會更相同 – ceciliaSHARP 2009-10-30 11:43:43

+0

@ zwi:它的「XAML」 – VoodooChild 2011-07-20 13:24:18