2009-10-29 33 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