WPF/Silverlight 与 WinRT

Question

我实际上从未在 WinRT 中构建过应用程序（也不是 HelloWorld），我对此非常怀疑。

我的问题是 WPF/Silverlight 中是否有 WinRT 中不存在的功能（不包括设计上不同实现的功能）？

这些方面对我来说是最重要的，也是我的问题的核心，因此决定是开始使用 WinRT 还是等待这些方面的实施：

• 实体框架？
• WCF RIA？
• MVVM 支持（棱镜）？？？
• 各种工具包（Silverlight/WPF 工具包），提供诸如DatePicker 等附加控件？

我不清楚 WinRT 是否完全针对 .NET 或它是如何工作的。

此外，WinRT 是仅客户端（如 WPF）应用程序，还是可以在远程客户端上运行而坐在服务器上（如 Silverlight）？

另外一个：向后兼容性怎么样，如果我开发一个 WinRT 应用程序，它是否能够在 Win XP 上运行？

我还是不明白为什么 MVVM 没有内联集成并且像 MVC 一样具有无缝的 IDE 支持。但这只是一个旁注。没有 MVVM 我不能使用 XAML，任何比 hello world 大一点的应用程序都更容易使用 MVVM。

answer之后更新

正如我对答案的评论，我确实喜欢 WinRT 的设计，但在我了解上述特定技术（EF、WCF-RIA + 验证、MVVM、SDK 和工具包）之前，这个问题仍未解决。显然，在我至少具备上述技术之前，我不会开始销售 WinRT 应用程序或深入研究它。

结论，作为一个他的大部分工作是 LOB 应用程序的人，在检查了一下之后，HTML5+JS 远不是 SL 的替代品。所以总而言之，我坚持 SL 并继续向我的客户推荐它。 SL 需要最少的开发时间，并且没有错误。 与 C# 相比，Javascript 是一种肮脏且容易出错的语言，没有模式也没有 nuttn。

一旦 EF+RIA+Prism+Toolkits 完全支持 WinRT，我将考虑以 Metro 方式使用我的 LOB 应用程序。

Answer 1

WinRT 基本上是一个 COM 对象的集合，这些对象封装了一堆 Win32 API，以符合 CLI 的程序集的形式公开。

Microsoft 修改了他们的 C++ 编译器以使用和生成 ECMA 335（即 CLI）元数据，而不是更传统的（主要是）仅 C++/COM 的 MIDL 或 lib 文件格式。 Microsoft 还修改了他们的“Chakra”Javascript 引擎，使其也可以使用和发出 CLI 元数据。

这意味着当以 WinRT 为目标时，Javascript 和 C++ 代码以及 .NET 语言当然可以使用 CLI 兼容（即 .NET）程序集，并且可以发出 CLI 兼容（即 .NET）程序集。

因此，可以使用 C++、任何 .NET 语言（即 C#、VB.NET、F#、Iron* 等）和 Javascript 编写 WinRT 代码。

如果您曾经编写过任何 .NET 代码，那么您会非常熟悉 WinRT API。 Windows 团队在设计 WinRT 时实际上寻求 .NET Framework 设计团队的帮助和指导，因此过去 11 年指导整个 .NET Framework 团队和大多数 .NET 社区的相同设计指南已应用于WinRT API。

坦率地说，WinRT 很漂亮 :)

WinRT 的主要影响是它将 System.IO 的文件、网络、流 IO 类替换为类似的 API，但仅支持异步 IO。这意味着您将无法编写在线程等待通过网络对文件系统或外部系统的调用返回时阻塞线程的应用程序，除非您采取明确的步骤。

这是一件好的事情。

幸运的是，C# v5 和 VB.NET v.next 的新 async/await 特性以及对 C++ 的特定支持意味着您不必从根本上改变在这个新的异步世界中编写代码的方式 -通常，您只需在调用异步 API 的方法签名中添加一个“async”关键字，然后在每个异步 API 调用前使用“await”关键字。

我强烈建议您观看Anders Hejlsberg's session，这将使整个事情变得非常清楚。当您在那里时，我还鼓励您观看其他几个 //BUILD 会话，尤其是 Harry Pierson's talk on using WinRT with C# & VB.NET 和 Mads 在 Async Made Simple in C# and VB 上的会话。

我还建议您查看几周前我在博客上发布的 improved Win8/WinRT platform architecture 图表，这应该会让事情变得更清晰。

至于 .NET 本身，正如我在上面的帖子中所阐述的那样，.NET 并没有“消失”。虽然 WinRT 应用程序中将禁止一些 .NET API（即阻止 IO API），但您所依赖的大多数 API 仍然存在并且可以完全访问。

关于 Silverlight： Silverlight 是一个浏览器插件。它是 WPF 的一个修改子集，并提供了一些非常强大和吸引人的特性。事实上，Silverlight XAML 引擎已被移入核心 Windows 团队，并用于 Windows8 中的大部分 Metro UI 渲染——甚至被操作系统本身使用！

最终结果是，您的大部分 Silverlight 代码几乎无需任何修改即可正常运行，而只是更改了一些“使用”命名空间。

BUILD available to watch here 提供了大量以 XAML 为中心的会话。

关于向后兼容性，目标是：

• 尽可能将要在 WinRT 以及 .NET 桌面应用程序、Windows Phone 等中使用的代码隔离到可移植程序集中。
• 需要获取特定平台依赖项并考虑手动加载它们或使用 IoC 将模块组合在一起的抽象代码。

坦率地说，我不认为 Microsoft 的工作是为每个场景编写每个框架。在野外有几种 MVVP 方法/框架，来自具有各种优点和缺点的各种人。如果你没有找到，那就创建一个并将它贴在 GITHub 上并成名 ;)

不过，最重要的是，没有什么能阻止您下载和试用 Win8 Consumer Preview 和 Dev11 Beta。去拿它们试试吧——我想你会发现它们很清爽:)

HTH。

更新#1 回应对 EF、WCF 等的特定支持：

您可以找到WinRT API surface area enumerated here in some detail。 core WCF API's are enumerated here。

但请注意，Microsoft 强烈建议不要使用网络通信在同一台计算机上的 Metro 应用程序和其他 Metro 应用程序或桌面应用程序/服务之间进行通信。阅读 this SO question 和 Kate Gregory 的回答 - 她链接到一个视频，其中详细讨论了这种情况。

如果您想与开箱即用的网络服务进行通信，那么您有多种选择，包括 WCF、套接字等。

关于 RIA：微软目前表示，如果您需要数据，则需要通过服务而不是直接从数据库中获取。 Metro 没有 ADO.NET，建议通过 OData、JSON、XML/HTTP 等显示数据。数据即服务在很大程度上是一种 RIA 方案，因此我希望 Metro 应用程序能够很好地支持 RIA。 Here's a BUILD session on this very subject 这可能会带来更多启示。

只有您可以判断 WinRT 是否支持您的特定方案。我认为最好的办法是下载这些位并开始探索。

根据 P&P 更新的路线图和指南更新 2： P&P 最近发布了一个新的roadmap and guidance，用于构建 Windows RT/Windows 8“商店”/“现代”LOB 应用程序。

本指南包括updates to Prism/Kona，还包括EntLib6 & Unity3 (IoC)。我鼓励任何对此领域感兴趣的人研究已发布的材料和参考应用程序 - 那里有一些很棒的东西:)

Answer 2

请注意，WinRT 面向 Windows 8 Metro 风格的应用程序，而不是使用 WPF 或 Winforms 开发的传统桌面应用程序 (Windows 7)。 Metro 风格的应用程序将仅通过 Windows 应用商店分发。 Microsoft 对 Windows 应用商店应用程序收取 30% 的费用。开发人员获得 70%。这与苹果收取的“税”相同。 对于 Metro 风格的 Internet Explorer 版本，忘记 Silverlight。它不支持插件。记住 Silverlight 是一个插件。桌面版 Internet Explorer 支持插件，因此支持 Silverlight。