Windows 8 运行时(WinRT/Windows 应用商店应用/Windows 10 通用应用)与 Silverlight 和 WPF 相比如何? [英] How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF?

查看:30
本文介绍了Windows 8 运行时(WinRT/Windows 应用商店应用/Windows 10 通用应用)与 Silverlight 和 WPF 相比如何?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试了解用于创建 的新 Windows 8 运行时Metro 风格的应用程序.我知道你可以将它与 XAML 一起使用,它基于 .NET 所以 C# 和 VB.NET可用于编写应用程序,但它似乎与 HTML、CSS、DOM 和 JavaScript 有关.

I am trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.

有人可以用 .NET UI 程序员可以理解的术语用几段来解释它是什么吗?(我错过了理解它所必需的关键".)

Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something "key" that is necessary to understand it.)

我们都知道 WPF、SilverlightWindows Forms 等将至少在 Intel 系统上继续在 Windows 8(和 Windows 10)下工作,所以请不要告诉我那个...

We all know that WPF, Silverlight, Windows Forms, etc. will keep working under Windows 8 (and Windows 10) on at least on Intel systems, so please don't tell me that...

推荐答案

在最低级别,WinRT 是在 ABI 级别定义的对象模型.它使用 COM 作为基础(因此每个 WinRT 对象都实现 IUnknown 并进行引用计数),并从那里构建.与旧的 COM 相比,它确实添加了相当多的新概念,其中大部分直接来自 .NET - 例如,WinRT 对象模型具有委托,并且事件以 .NET 样式完成(具有委托和添加/删除订阅者)方法,每个事件一个)而不是事件源和接收器的旧 COM 模型.在其他值得注意的事情中,WinRT 还具有参数化(通用")接口.

At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.

另一个重大变化是所有 WinRT 组件都有可用的元数据,就像 .NET 程序集一样.在 COM 中,类型库有点类似,但并非每个 COM 组件都有它们.对于 WinRT,元数据包含在 .winmd 文件中 - 在 Developer Preview 中查看C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\".如果你四处看看,你会发现它们实际上是没有代码的 CLI 程序集,只是元数据表.事实上,您可以使用 ILDASM 打开它们.请注意,这并不意味着 WinRT 本身是受管理的 - 它只是重复使用文件格式.

One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.

然后根据该对象模型实现了许多库 - 定义 WinRT 接口和类.再次,查看上面提到的Windows Metadata"文件夹,看看里面有什么;或者直接在 VS 中启动对象浏览器并在框架选择器中选择Windows 8.0",以查看所涵盖的内容.那里有很多,它不单独处理 UI - 您还可以获得诸如 Windows.Data.Json、或 Windows.Graphics.Printing 或 <代码>Windows.Networking.Sockets.

Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.

然后你会得到几个专门处理 UI 的库——大部分是 Windows.UIWindows.UI.Xaml 下的各种命名空间.其中很多与 WPF/Silverlight 命名空间非常相似 - 例如Windows.UI.Xaml.ControlsSystem.Windows.Controls 紧密匹配;Windows.UI.Xaml.Documents 等的同上.

Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces - e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documents etc.

现在,.NET 能够直接引用 WinRT 组件,就像它们是 .NET 程序集一样.这与 COM Interop 的工作方式不同 - 您不需要任何中间工件,例如互操作程序集,您只需 /r 一个 .winmd 文件,并且其元数据中的所有类型及其成员都对您可见如果它们是 .NET 对象.请注意,WinRT 库本身是完全本机的(因此使用 WinRT 的本机 C++ 程序根本不需要 CLR)——将所有这些内容公开为托管内容的神奇之处在于 CLR 本身,并且是相当低的级别.如果您编写了一个引用 .winmd 的 .NET 程序,您会发现它实际上看起来像一个外部程序集引用 - 没有像类型嵌入那样的花招.

Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just /r a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.

这也不是一个简单的映射 - CLR 会尽可能将 WinRT 类型调整为它们的等效类型.所以例如GUID、日期和URI分别变为System.GuidSystem.DateTimeSystem.UriIIterableIVector 等 WinRT 集合接口变为 IEnumerableIList代码>;等等.这是双向的 - 如果您有一个实现 IEnumerable 的 .NET 对象,并将其传递回 WinRT,它会将其视为 IIterable.

It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable<T> and IVector<T> become IEnumerable<T> and IList<T>; and so on. This goes both ways - if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it'll see it as IIterable<T>.

最终,这意味着您的 .NET Metro 应用程序可以访问现有标准 .NET 库的子集,以及(本机)WinRT 库,其中一些 - 特别是 Windows.UI - 在 API 方面看起来与 Silverlight 非常相似.您仍然使用 XAML 来定义您的 UI,并且您仍然处理与 Silverlight 中相同的基本概念 - 数据绑定、资源、样式、模板等.在许多情况下,可以通过 使用简单地移植 Silverlight 应用程序 新的命名空间,并在代码中调整 API 的一些地方.

Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly Windows.UI - look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted.

WinRT 本身与 HTML 和 CSS 没有任何关系,它与 JavaScript 的关系仅在于它也在 JavaScript 中公开,类似于它在 .NET 中的处理方式.当您在 .NET Metro 应用程序中使用 WinRT UI 库时,您不需要处理 HTML/CSS/JS(好吧,我想,如果您真的想要,您可以托管一个 WebView 控件……).您所有的 .NET 和 Silverlight 技能都与此编程模型密切相关.

WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebView control...). All your .NET and Silverlight skills remain very much relevant in this programming model.

这篇关于Windows 8 运行时(WinRT/Windows 应用商店应用/Windows 10 通用应用)与 Silverlight 和 WPF 相比如何?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆