我已经在一个执行数值计算的库上工作了一段时间。它是用纯本地C ++编写的，直到现在我一直在使用简单的控制台应用程序来测试它的功能。
现在是在库顶部构建GUI的时候了 - 更好地显示结果表并以图形形式呈现它们。
我一直计划使用WPF来实现UI，并花了一些时间研究它，但我现在有了第二个想法。我对WPF的担忧是：
我担心因为人们离开WPF遇到类似问题的消息更加复杂 - 最新且最引人注目的是Evernote。
你会建议我坚持原来的计划并使用WPF吗？
如果是这样，您如何看待上述问题？ 如果没有，我可以使用哪些替代库来创建高质量的Windows GUI？
修改
感谢Reed Copsey解决我的个人观点。回复表明，我对WPF的大多数问题都可以解决。
似乎使用WPF将涉及比理想工作更多的工作 - 包括编写互操作代码和进行调整以确保良好的性能和高质量。人们普遍同意这样的说法：尽管如此，制作高质量UI的最佳方法是使用WPF - 而不是使用任何其他框架吗？
答案 0 :(得分：6)
我会尝试按顺序解决这些问题。掠夺者：在我看来，在大多数情况下，答案是肯定的。
为了用户界面，是否值得将我的程序与.NET框架耦合？
这取决于接口要求。您是否需要一个好的，可靠的现代用户界面？如果是这样，您将需要使用正确的工具来提供该要求。
.NET和WPF似乎增加了许多形式的开销，包括：
- 程序复杂性
- 使用.NET意味着使用第二种语言 - 因此编写了许多混乱的互操作代码。
您可以通过C ++ / CLI使用GDI +，并使用一种语言处理所有内容。话虽这么说，人们使用其他语言的部分原因是生产力 - 与用C ++制作GUI相比，它实际上非常非常快。通过C ++ / CLI的互操作代码根本不是很混乱，至少在你的例程是基于类的情况下不是这样。
运行时性能 - 特别是，WPF应用程序启动似乎很慢。
这在某种程度上可能是一个问题。但是，您可以做很多事情来缓解它 - 但是这可能总是比精简的本机代码库慢一点，因为它必须启动CLR +库。
部署 - .NET框架安装是否快速而简单？是否需要重启机器？
通常，两者都是。话虽这么说，大多数人已经安装了框架（特别是如果你的目标是.NET 3.5，但4.0很好），所以这是一个非问题。我总是认为这是一次性的事情 - 我宁愿在一段时间内交换一个很好的用户体验，特别是当它是一个相对无痛的部署时（.NET很容易安装，只是大而且有点耗时）。
渲染质量 - 这在WPF 4中得到了改进，但在某些领域，标准元素的显示仍然很差。
我在这里非常不同意。 WPF是（特别是第4版），是优质用户界面的首选平台。在WPF中击败渲染质量选项很难 -
关注未来的性能和质量是否会提高 - 是否真的在微软内部不再强调WPF（支持Silverlight）？
没有。在WPF未来的PDC上甚至有一个很好的谈话。 Silverlight获得了更多的新闻，但这主要是因为它不是那么成熟的技术，所以它的变化更快。 WPF仍然是他们的顶级UI体验，并且仍然增加了新功能。它也是与本机代码互操作的建议平台 - 虽然在SL中使用COM是可能的，但它在WPF中并不令人愉快。
根据PDC谈话，性能，线程问题和空域问题似乎是未来的改进。有关详细信息，请观看“The Future of WPF。”