WPF/Silverlight VS WinRT [英] WPF/Silverlight VS WinRT

问题描述

我实际上从未在 WinRT 中构建过应用程序(也没有构建过 HelloWorld)，而且我非常怀疑.

I never actually built an application (nor a HelloWorld) in WinRT, and I'm very suspicious.

我的问题是 WPF/Silverlight 中是否存在 WinRT 中不存在的功能(不包括设计上实现不同的功能)?

My question is if there are features in WPF/Silverlight that don't exist in WinRT (excluding features that are implemented differently by design)?

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

And these aspects are most important to me and are the core of my question, and in result, decision to whether start using WinRT or wait for these to be implemented for it:

• 实体框架?
• WCF RIA?
• MVVM 支持(Prism)???
• 各种工具包(Silverlight/WPF 工具包)，提供额外的控件，例如 DatePicker 等?

我不清楚 WinRT 是否完全针对 .NET 或其工作原理.

It's not clear to me whether WinRT fully targets .NET or how it works.

此外，WinRT 是仅限客户端(如 WPF)的应用程序还是可以在远程客户端上运行，同时位于服务器上(如 Silverlight)?

Also, is WinRT a client-only (like WPF) application or can be ran on a remote client while sitting on a server (like Silverlight)?

另一个:向后兼容性如何，如果我开发一个 WinRT 应用程序，它是否能够在 Win XP 上运行?

Another one: What about backwards compatibility, if I develop a WinRT app, will it ever be able to work on Win XP?

我无论如何都无法理解为什么 MVVM 没有内联集成并且像 MVC 那样具有无缝的 IDE 支持.但这只是一个旁注.如果没有 MVVM，我就无法使用 XAML，任何比 hello world 大一点的应用程序都可以通过 MVVM 轻松实现.

I anyway can't understand why MVVM is not integrated inline and has seamless IDE support as MVC has. but that's just a side note. I can't use XAML without MVVM, any app that is a bit bigger than hello world is easier to do with MVVM.

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

As I commented on the answer, I do like the design of WinRT, but the question remains unsolved until I know about the specific technologies mentioned above (EF, WCF-RIA + Validation, MVVM, SDKs and Toolkits). And obviously, I'm not gonna start selling WinRT apps or digging into it until I have the above techs as a least.

结论，作为他大部分工作都是LOB应用程序的人，经过一番检查，HTML5+JS远不是SL的替代品.所以总而言之，我坚持使用 SL 并继续向我的客户推荐它.SL 花费最少的开发时间，并且没有错误.与 C# 相比，Javascript 是一种肮脏的、容易出错的语言，没有模式也没有坚果.

Conclusion, as one who most of his work is LOB apps, after checking around a bit, HTML5+JS is far from being an alternative to SL. So for conclusion, I stick to SL and keep on recommending it to my customers. SL takes the least development time, and is bug free. Javascript is a dirty error-prone language, no pattern and no nuttn, compared to C#.

一旦 EF+RIA+Prism+Toolkits 完全支持 WinRT，我将考虑采用地铁方式使用我的 LOB 应用程序.

Once EF+RIA+Prism+Toolkits are fully supported for WinRT, I will consider taking my LOB apps the metro way.

推荐答案

WinRT 基本上是一个 COM 对象的集合，这些对象包装了一堆 Win32 API'，公开为 CLI 兼容的程序集.

WinRT is basically a collection of COM objects that wrap a bunch of Win32 API', exposed as CLI-compliant assemblies.

Microsoft 修改了他们的 C++ 编译器以使用和生成 ECMA 335(即 CLI)元数据，而不是更传统的和(主要)仅 C++/COM 的 MIDL 或 lib 文件格式.微软还修改了他们的Chakra"Javascript 引擎，以使用和发出 CLI 元数据.

Microsoft modified their C++ compiler to consume and generate ECMA 335 (i.e. CLI) metadata rather than the more traditional and (largely) C++/COM-only MIDL or lib file formats. Microsoft also modified their "Chakra" Javascript engine to also consume and emit CLI metadata.

这意味着，当以 WinRT、Javascript 和 C++ 代码以及 .NET 语言为目标时，当然可以使用符合 CLI(即 .NET)的程序集并可以发出与 CLI 兼容(即 .NET)的程序集.

This means that when targeting WinRT, Javascript and C++ code, along with .NET languages, of course, can consume CLI-compliant (i.e. .NET) assemblies and can emit CLI-compatible (i.e. .NET) assemblies.

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

So, one can write WinRT code in C++, any .NET language (i.e. C#, VB.NET, F#, Iron*, etc) and in Javascript.

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

The WinRT API's will be VERY familiar to you if you've ever written any .NET code. The Windows team actually sought the help & guidance of the .NET Framework design team when designing WinRT, so the same design guidelines that have guided the entire .NET framework team and most of the .NET community for the last 11 years have been applied to the WinRT API's.

坦率地说，WinRT 很漂亮:)

WinRT is, quite frankly, beautiful :)

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

WinRT's primary impact is that it replaces System.IO's file, network, stream IO classes with similar API's but which ONLY support async IO. This means that you will not be able to write apps that block threads while they wait for calls to the filesystem or external systems via the network to return unless you take explicit steps to do so.

这是一件好事.

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

Luckily, the new async/await features of C# v5 & VB.NET v.next, along with specific support for C++ mean that you don't have to go and fundamentally change how you write code in this new async world - typically you just need to add an "async" keyword to method signatures that call async API's and then use the 'await' keyword prefixing each async API call.

我强烈建议您观看 Anders Hejlsberg 的会议把整件事说清楚.当您在那里时，我还鼓励您观看其他几个//BUILD 会议，尤其是 Harry Pierson 关于在 C# 中使用 WinRT 的演讲 &VB.NET 和 Mads 的关于 Async Made Simple in C# 和VB.

I STRONGLY encourage you to watch Anders Hejlsberg's session which should make this whole thing very clear. While you're there, I also encourage you to watch several of the other //BUILD sessions, especially Harry Pierson's talk on using WinRT with C# & VB.NET and Mads' session on Async Made Simple in C# and VB.

我还建议您查看 改进的 Win8/WinRT 平台架构图，我在几周前的博客中写过，它应该让事情变得更清晰.

I'd also recommend that you take a look at the improved Win8/WinRT platform architecture diagram that I blogged a few weeks back which should make things a little clearer.

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

As for .NET itself, as I articulate in my post above, .NET is not "going away". While a few of the .NET API's will be prohibited in WinRT apps (i.e. blocking IO API's), most of the API's you depend upon remain and are fully accessible.

关于 Silverlight:Silverlight 是一个浏览器插件.它是 WPF 的一个修改子集，并提供了一些非常强大和有吸引力的功能.事实上，Silverlight XAML 引擎被转移到核心 Windows 团队中，并用于 Windows8 中的大多数 Metro UI 渲染 - 甚至由操作系统本身使用！

Regarding Silverlight: Silverlight is a browser plug-in. It's a modified-subset of WPF and offers some very powerful and attractive features. So much so, in fact, that the Silverlight XAML engine was moved into the core Windows team and is used for most of the Metro UI rendering in Windows8 - even by the OS itself!

最终结果是您的大部分 Silverlight 代码几乎不需要任何修改即可正常运行，而不仅仅是更改一些使用"命名空间.

The net result is that most of your Silverlight code will run just fine with barely any modification, other than just changing a few 'using' namespaces.

BUILD 可以在此处观看.

关于向后兼容性，旨在:

With regards backward compatibility, aim to:

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

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

Frankly, I don't think it's Microsoft's job to write every framework for every scenario. There are several MVVP approaches/frameworks out there in the wild from various people with various pro's and con's. And if you don't find one then create one and stick it up on GITHub and become famous ;)

不过，最重要的是，几乎没有什么能阻止您下载和试用 Win8 Consumer Preview &Dev11 测试版.去拿它们试试看——我想你会发现它们非常令人耳目一新:)

Above all, though, there's little stopping you from downloading and trying Win8 Consumer Preview & Dev11 Beta. Go get them and try them out - I think you'll find them very refreshing :)

HTH.

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

Update#1 in answer to the specific support for EF, WCF, etc:

您可以找到此处列举的 WinRT API 表面积一些细节.列举了 核心 WCF API这里.

You can find the WinRT API surface area enumerated here in some detail. The core WCF API's are enumerated here.

但是请注意，Microsoft 强烈建议不要使用网络通信在同一台计算机上的 Metro 应用程序和其他 Metro 应用程序或桌面应用程序/服务之间进行通信.阅读 这个问题 &Kate Gregory 的回答 - 她链接到详细讨论此场景的视频.

Note, however, that Microsoft is strongly recommending against using network coomms to communicate between Metro apps and other metro apps or desktop apps/services on the same machine. Read this SO question & Kate Gregory's answer - she links to a video where this scenario is discussed in detail.

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

If you want to communicate with off-box network services, then you have a wide variety of options including WCF, sockets, etc.

关于 RIA:微软目前表示，如果您需要数据，您需要通过服务而不是直接从数据库获取数据.Metro 没有 ADO.NET，建议通过 OData、JSON、XML/HTTP 等来显示数据.数据即服务在很大程度上是一种 RIA 方案，因此我希望 Metro 应用程序能够很好地支持 RIA.这是一个关于这个主题的 BUILD 会议，它可能会提供更多信息.

Regarding RIA: Microsoft are currently saying that if you want data, you'll need to get it via a service rather than directly from a DB. There's no ADO.NET for Metro and the recommendation is to surface data via OData, JSON, XML/HTTP, etc. Data as a service is very much a RIA scenario, so I expect RIA to be well supported for Metro apps. Here's a BUILD session on this very subject which may shed more light.

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

Only you can tell whether or not your specific scenarios are supported in WinRT. I think your best bet would be to download the bits and start exploring.

根据 P&P 的更新路线图和指南更新 2:P&P 最近发布了用于构建 Windows RT/Windows 8 的新路线图和指南商店"/现代"LOB 应用程序.

Update 2 following P&P's updated roadmap and guidance: P&P have recently published a new roadmap and guidance for building Windows RT / Windows 8 "store" / "modern" LOB apps.

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

This guidance includes updates to Prism/Kona and also includes EntLib6 & Unity3 (IoC). I encourage anyone interested in this space to study the published materials and reference apps - there is some great stuff in there :)

这篇关于WPF/Silverlight VS WinRT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！