WPF替代品

Question

WPF被定位为WinForms的继任者，但鉴于微软放弃工具包（以及我认为WPF中的“膨胀”）的做法，是否有任何推荐的替代方案？

Answer 1

我认为你不必担心WPF被抛弃了。 WinForm已经存在了很长时间，WPF是 的替代品。

鼓胀症？我不知道......似乎是从WinForms到我的巨大升级。如果存在膨胀，它总会存在，因为在所有内容下面都是Win32 API。在从头开始重写之前，我认为没有什么是完美的。因为针对Windows平台的每个工具包都必须处理...我宁愿选择WPF和ReSharper ......

Answer 2

微软认真对待WPF的另一个迹象是它已经习惯于制作Visual Studio 2010.XAML似乎不仅仅被WPF（Workflow Foundation，Communication Foundation）使用。

过去5年我一直在WinForms编码，起初我对WPF也持怀疑态度。但在阅读了几本书并在WPF中尝试我的第一个应用程序后，我开始看到它的美丽！

我对自己在WPF应用程序中需要多少“粘合”代码以及在WinForms中完成它的方式感到惊讶。这是一个例子：我必须显示一个简单的直方图。在WinForms中，我会写一个自定义控件并自己处理渲染。在WPF中，我在没有一行代码的情况下从xaml完成了所有操作！我只是将数据样本绑定到列表框，将列表框的布局模板替换为水平堆栈面板，并将项目模板替换为高度绑定到样本值的矩形！

Answer 3

MS没有放弃工具包的做法（WinForms，MFC，ActiveX和Win32都在积极开发），而“膨胀”实际上是你现在可能不需要的新功能，但你很有可能将来需要。

如果您不想要膨胀并且只使用MS无法停止支持的API，那么欢迎您直接使用Win32 API。

Answer 4

我相信5个开发者中有4个从未超越技术的表面，他们只想拖延和放弃。删除几个控件，写几行代码并获得一些东西＆amp;跑步，也许用谷歌搜索一些样品，以帮助解决一些问题，就是这样。对于这些人来说，膨胀不是他们字典中的一个词。

我认为，在开始使用该技术编写代码之前，我更愿意深入研究并真正弄清楚技术如何实际运作。今天，我花了一个小时左右来研究WPF内置命令是如何工作的，并且在反射器的帮助下我设法跟踪如何为普通文本框控件执行简单的内置Cut命令，并猜测什么，当文本更改事件被提出进行剪切操作时，调用堆栈上有大约30个调用，这不是代码膨胀吗？

WPF肯定有许多强大的功能，但它们确实需要付出代价。在某些方面，我觉得WPF是WinForms MFC对Win32 API来说是什么; WPF和MFC都至少有“基础”这个词，但是看看WPF是否会出现与MFC相同的命运会很有趣。

Answer 5

这取决于您最喜欢的编程语言，但Qt是一个很好的C ++工具包。它具有令人印象深刻的功能，是免费的，并且与GUI工具包的平台无关。

Answer 6

Qt Quick（QML）是要走的路。它具有极其尖锐的设计，并且不会受到XML不可读性的污染。

Answer 7

Adobe AIR是强有力的竞争对手。如果您的目标是创建具有丰富用户界面的跨平台应用程序，请查看此文件。

Answer 8

首先，我喜欢WPF！我看不出有任何优雅的/直接的方式，以实现在的WinForms界面设计相同的功能和灵活性......这就是说，它是很伤心地看到，WPF已不再支持微软内部。实际上有些人，包括“内部人士”已经声明MS已经转移了WPF的焦点，而Silverlight现在是Windows Phone 7应用程序框架（不再是取代Flash的了）：

http://www.theregister.co.uk/2010/09/09/microsoft_html_5/

许多人，包括现任WPF领导人，否认了这一点，但我发现这实际上可能有一些真相。 HTML5肯定会成为富（Web）客户端接口的“事实上的”标准。它与WPF重叠很多，并且还做了很多其他事情。它可以“轻松”扩展到适用于非Web富客户端应用程序，我相信MS将投资于此，以便在Web，移动和Windows目标的开发工具中处于领先地位。

如果我已经处于WPF项目的中间，我不会害怕放弃，但我不会像许多人已经说过的那样在WPF中启动它：在没有提供迁移的情况下放弃像WPF这样的东西并不是那么简单道路并支持它多年。

那么，MS世界中WPF的当前替代品呢？我不认为我们已经有一个，也许在Silverlight中使用它的子集是现在的方法。但是，在接下来的几年中，HTML5可能是WPF的替代品。