wpf - 用于构建 Windows 应用程序的长期客户端 API 策略？

Question

我开始构建一个新的 Windows 应用程序，它需要一个相当丰富的客户端界面，但我不知道我应该使用什么客户端 API（WPF、Silverlight、WinRT、HTML5 等？）。实际上，我很不安，因为 MS 提供的指导很少能帮助人们做出这个决定。

不同客户端 API 的 MS 支持策略是什么？每个人的寿命是多少？我不想在当前已知且受支持的 API（WinForms 或 WPF）中编写完整的客户端应用程序，只是为了在两年内获得 MS 对它的拉取支持，并被迫重新编写它。但我真的不能在 WinRT 中编写它，因为大规模企业部署至少要 2 年才能到位。那么我是否被迫采用基于 Web 的方法，例如 Silverlight？它的支持/长寿故事是什么？我改用 HTML5 吗？如果我走那条路，使用 Microsoft 堆栈而不是仅仅使用开源堆栈有什么好处？

感觉就像我在这里总共遇到了 22 个问题，我无法从微软那里找到任何好的指导。从事情的声音来看，在 WPF 中编写软件是愚蠢的，因为它被删除（很快？），但我不能在 WinRT 中编写它，因为公司不会在几年内部署它。这整件事对我来说完全是疯狂的。

想法或想法？

Answer 1

考虑到您的经验，以及您所说的“Windows 应用程序”（不是 Web 应用程序）这一事实，我肯定会选择 WPF。请记住，无论使用一组不同的底层 API，WinRT 仍然保留了 WPF 的核心概念：XAML、绑定、样式、触发器、数据模板等。因此，虽然您确实无法将代码从 WPF 复制粘贴到 WinRT 并按 F5，但在这些技术（即与视图无关的 ViewModel）与 HTML、Winforms 和其他框架之间有大量工作可以兼容有完全不同的做事方式，需要不同的心态来工作。

至于微软会做什么。我不会太担心，因为有证据表明，即使是像 VB6 这样的旧技术在当前版本的操作系统中仍然保持“可运行”，我认为没有必要即使 Metro 成为标准，也要在 2 年内重写整个应用程序。Metro 无法取代桌面传统应用程序，而后者仍被证明是数据密集型应用程序的最佳选择。

而且，如果真的到了我们所有人都真正被推入 WinRT 的时刻，那么对于那些已经使用 MVVM 和 XAML 编写 SL/WPF 应用程序的人来说，这将比那些使用 HTML 或 winforms 的人容易得多。

无论您最终选择什么，请确保尽可能将应用程序的功能与 UI 分开。当需要更改 UI 框架时，这肯定会变得容易得多。

这只是我个人的看法，我也想听听其他人对这个问题的看法。

编辑：另一个非常重要的方面是，如果你真的需要制作一个动画密集的 UI，或者远离传统的战舰灰色 UI，你最终会因为 winforms 或 HTML/ Javascript 地狱，所有浏览器都以不同的方式呈现事物，更不用说这些技术所需的代码量来实现在 WPF / SL / WinRT 中需要 3 行 XAML 的东西。