.net - WPF/银光VS WinRT

Question

我从来没有在WinRT中构建过一个应用程序（也没有一个HelloWorld），我对此非常怀疑。

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

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


实体框架？
WCF RIA？
MVVM支持（Prism）？？？
各种工具包（Silverlight / WPF工具包）是否提供诸如DatePicker等的其他控件？


我不清楚WinRT是否完全针对.NET或其工作方式。

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

另一个问题：向后兼容性如何？如果我开发WinRT应用程序，它将能够在Win XP上运行吗？

无论如何，我还是不明白为什么MVVM没有被内联集成并且像MVC一样具有无缝的IDE支持。但这只是一个旁注。如果没有MVVM，我将无法使用XAML，使用MVVM可以轻松完成任何比hello world大一些的应用程序。

answer之后更新

正如我对答案所作的评论一样，我确实喜欢WinRT的设计，但是直到我了解上述特定技术（EF，WCF-RIA +验证，MVVM，SDK和工具包）之前，这个问题一直没有解决。显然，除非我至少具备上述技术，否则我不会开始销售WinRT应用或进行深入研究。

结束语，作为他的大部分工作是LOB应用程序，经过一番检查之后，HTML5 + JS远不是SL的替代品。因此，为了得出结论，我坚持使用SL并继续将其推荐给我的客户。 SL占用最少的开发时间，并且没有错误。
与C＃相比，Javascript是一种肮脏的易于出错的语言，没有模式，也没有螺母。

WinRT完全支持EF + RIA + Prism + Toolkits之后，我将考虑采用LOB应用程序。

Answer 1

WinRT本质上是一些COM对象的集合，这些对象包装了一堆Win32 API（公开为CLI兼容程序集）。

微软修改了他们的C ++编译器以使用和生成ECMA 335（即CLI）元数据，而不是使用更传统的（主要是）仅C ++ / COM的MIDL或lib文件格式。微软还修改了其“ 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的主要影响是它用类似的API替换了System.IO的文件，网络，流IO类，但仅支持异步IO。这意味着您将无法编写阻止线程的应用程序，因为它们等待通过网络对文件系统或外部系统的调用返回，除非您采取明确的步骤这样做。

这是一件好事。

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

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

我还建议您看一下我几周前写的 Async Made Simple in C# and VB图，这应该使事情更加清楚。

至于.NET本身，正如我在上面的文章中明确指出的那样，.NET并没有“消失”。尽管WinRT应用程序中将禁止使用某些.NET API（即阻止IO API），但您依赖的大多数API仍可保留并且可以完全访问。

关于Silverlight：Silverlight是浏览器插件。它是WPF的修改子集，并提供了一些非常强大和吸引人的功能。事实如此，Silverlight XAML引擎已移入Windows核心团队，并用于Windows8中的大多数Metro UI渲染-甚至是操作系统本身！

最终结果是，除了更改一些“使用”命名空间之外，几乎所有的Silverlight代码都可以在几乎没有任何修改的情况下正常运行。

BUILD improved Win8/WinRT platform architecture中有大量针对XAML的会话。

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


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


坦白说，我不认为为每种情况编写每个框架都不是微软的工作。各种各样的MVVP方法/框架从各种各样的人那里获得了各种利弊。如果找不到，请创建一个并将其粘贴在GITHub上并出名；）

但最重要的是，您几乎没有阻止您下载并尝试Win8 Consumer Preview＆Dev11 Beta。去拿去试试看吧-我想你会发现它们非常清爽:)

HTH。


更新＃1以回答对EF，WCF等的特定支持：


您可以找到 available to watch here。 WinRT API surface area enumerated here in some detail。

但是请注意，Microsoft强烈建议不要使用网络命令在同一台计算机上的Metro应用程序与其他Metro应用程序或桌面应用程序/服务之间进行通信。阅读 core WCF API's are enumerated here和Kate Gregory的答案-她链接到视频，其中详细讨论了这种情况。

如果要与现成的网络服务进行通信，则可以使用多种选择，包括WCF，套接字等。

关于RIA：Microsoft当前在说，如果您想要数据，则需要通过服务而不是直接从数据库获取数据。没有用于Metro的ADO.NET，建议通过OData，JSON，XML / HTTP等来显示数据。数据即服务在很大程度上是一种RIA方案，所以我希望Metro应用程序能够很好地支持RIA。 this SO question可能会显示更多信息。

只有您可以说出WinRT是否支持您的特定方案。我认为您最好的选择是下载这些资料并开始探索。


按照P＆P更新的路线图和指南进行更新2：
P＆P最近发布了新的 Here's a BUILD session on this very subject，用于构建Windows RT / Windows 8“商店” /“现代” LOB应用程序。


本指南包括 roadmap and guidance，还包括 updates to Prism/Kona。我鼓励对此空间感兴趣的任何人学习已出版的材料和参考应用程序-那里有很多很棒的东西:)