Как Windows 8 Runtime (приложения для WinRT/Windows Store/Windows 10 Universal App) сравниваются с Silverlight и WPF?

Ответ 1

На самом низком уровне WinRT является объектной моделью, определенной на уровне ABI. Он использует COM в качестве базы (поэтому каждый объект WinRT реализует IUnknown и выполняет пересчет) и строит оттуда. Он добавляет довольно много новых концепций по сравнению с COM старыми, большинство из которых поступают непосредственно из .NET - например, объектная модель WinRT имеет делегатов, а события выполнены .NET-стиле (с делегатами и добавлением/удалением подписчика методы, по одному на событие), а не старую COM-модель источников и поглотителей событий. Из других важных особенностей WinRT также имеет параметризованные ( "общие" ) интерфейсы.

Еще одно большое изменение заключается в том, что все компоненты WinRT имеют метаданные, доступные для них, как и сборки .NET. В COM вы, вроде бы, имели это с typelib, но не каждый COM-компонент имел их. Для WinRT метаданные содержатся в файлах .winmd - загляните внутрь "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata \" в Preview Preview. Если вы соскучитесь, вы увидите, что они на самом деле являются сборками CLI без кода, а всего лишь таблицами метаданных. Вы можете открыть их с помощью ILDASM. Обратите внимание: это не означает, что WinRT сам управляется - он просто повторно использует формат файла.

Затем в рамках этой объектной модели реализовано несколько библиотек, определяющих интерфейсы и классы WinRT. Опять же, посмотрите на папку "Метаданные Windows", упомянутую выше, чтобы увидеть, что там; или просто запустите Object Browser в VS и выберите "Windows 8.0" в селекторе фреймворка, чтобы увидеть, что покрыто. Там много, и он не касается только пользовательского интерфейса - вы также получаете пространства имен, такие как Windows.Data.Json или Windows.Graphics.Printing, или Windows.Networking.Sockets.

Затем вы получаете несколько библиотек, которые конкретно занимаются пользовательским интерфейсом - в основном это будут различные пространства имен под Windows.UI или Windows.UI.Xaml. Многие из них очень похожи на пространства имен WPF/Silverlight - например, Windows.UI.Xaml.Controls близко соответствует System.Windows.Controls; то же самое для Windows.UI.Xaml.Documents и т.д.

Теперь .NET имеет возможность напрямую ссылаться на компоненты WinRT, как если бы они были сборками .NET. Это работает иначе, чем COM Interop - вам не нужны какие-либо промежуточные артефакты, такие как сборки interop, вы просто /r файл .winmd, и все типы и их члены в своих метаданных становятся видимыми для вас, как если бы они были объектами .NET, Обратите внимание, что сами библиотеки WinRT полностью родные (и поэтому на родные программы на С++, которые используют WinRT, вообще не требуется CLR) - магия, которая раскрывает все, что управляется, находится внутри самой среды CLR, и является довольно низким уровнем. Если вы ildasm используете .NET-программу, которая ссылается на .winmd, вы увидите, что она на самом деле похожа на ссылку на внешнюю сборку - там нет ловкости ручных трюков, таких как встраивание типов.

Это не тупое отображение, либо - CLR пытается, по возможности, адаптировать типы WinRT к их эквивалентам. Так, например, GUID, даты и URI становятся System.Guid, System.DateTime и System.Uri соответственно; Интерфейсы коллекции WinRT, такие как IIterable<T> и IVector<T>, становятся IEnumerable<T> и IList<T>; и так далее. Это происходит в обоих направлениях - если у вас есть объект .NET, который реализует IEnumerable<T> и передает его обратно в WinRT, он будет выглядеть как IIterable<T>.

В конечном итоге это означает, что ваши приложения .NET Metro получают доступ к подмножеству существующих стандартных библиотек .NET, а также к (родным) библиотекам WinRT, некоторые из которых - особенно Windows.UI - выглядят очень похожими на Silverlight, API-интерфейс. У вас все еще есть XAML для определения вашего пользовательского интерфейса, и вы по-прежнему имеете дело с теми же базовыми понятиями, что и в Silverlight - привязками данных, ресурсами, стилями, шаблонами и т.д. Во многих случаях можно переносить приложение Silverlight просто с помощью using новых пространств имен и настройки нескольких мест в коде, где был настроен API.

Сам WinRT не имеет ничего общего с HTML и CSS, и он имеет отношение к JavaScript только в том смысле, что он также отображается там, подобно тому, как это делается для .NET. Вам не нужно иметь дело с HTML/CSS/JS, когда вы используете библиотеки WinRT UI в своем приложении .NET Metro (ну, я думаю, если вы действительно этого захотите, вы можете разместить элемент управления WebView...). Все ваши навыки .NET и Silverlight остаются очень актуальными в этой модели программирования.

Ответ 2

Из Build ключевое слово:

Они предоставляют общие API-интерфейсы как для приложений HTML/CSS/JavaScript, так и для приложений С#/XAML. С# и XAML будут использоваться, но это не будет WPF или Silverlight точно.

Ответ 3

Основная идея заключается в том, что сейчас есть две дорожки разработки - Desktop и Metro.

• На рабочем столе находятся старые приложения.
• Новый класс приложений, приложений Metro, может быть построен несколькими способами, в том числе с помощью VB.NET, С# или С++. Эти три варианта языка могут использовать XAML для создания пользовательского интерфейса. Альтернативой является использование JavaScript/HTML5/CSS для разработки как кода пользовательского интерфейса, так и кода приложения.

Некоторые важные моменты:

• Windows 8 похожа на масштабируемую ОС мобильного телефона.
• В Metro нет перекрывающихся окон верхнего уровня, так же как их нет на мобильном телефоне. Если вы хотите использовать приложение стиля MDI, вам нужно оставаться на рабочем столе.
• Приложения в стиле Metro автоматически приостанавливаются, если их не видно. Это было сделано для продления срока службы батареи. Это означает, что для многих существующих настольных приложений, которые выполняют фоновую обработку, даже если пользователь не взаимодействует с ними, это не имеет смысла для переноса на Metro.
• ARM-версия Windows 8 не будет поддерживать настольные приложения. Поэтому, если вы хотите написать приложение и хотите, чтобы он работал с любой версией Windows, это должно быть приложение Metro.

Ответ 4

Там изменена версия архитектуры, которая, несомненно, поможет вам понять, где именно находятся вещи. Один из telinik ninjas побеседовал с командой

Здесь вы можете увидеть, где стоит CLR. Структура .NET теперь имеет два профиля

1-.NET Metro-профиль (CLR, работающий с приложением Metro)

2- Профиль клиента .NET(среда выполнения CLR для приложений С# и VB.NET)

Надеюсь, это даст вам более четкую картину. Прочитайте полную статью в Плохая картина стоит тысячи длительных обсуждений..

Ответ 5

Много деталей из Microsoft здесь.

Время выполнения Windows отображается с использованием метаданных API (файлы .winmd). Это тот же формат, который используется платформой .NET(Ecma-335). Базовый бинарный контракт облегчает вам доступ к API-интерфейсам Windows Runtime непосредственно на языке разработки по вашему выбору. Форма и структура API-интерфейсов Windows Runtime могут быть поняты как статическими языками, такими как С#, так и динамическими языками, такими как JavaScript. IntelliSense доступен в JavaScript, С#, Visual Basic и С++.

Вкратце, Windows Runtime - это новый набор библиотек, отображающих функциональность Windows и доступные для JavaScript/С#/VB/С++. Каждый язык был создан, чтобы понимать и иметь возможность называть их напрямую, а не проходить через какой-то слой thunking.

Silverlight и WPF - это разновидности XAML, которые запускаются на CLR. Среди других функций Windows Runtime предоставляет версию XAML, очень похожую на Silverlight, но делает это по-своему, а не через CLR. Его можно получить из CLR, но также из С++.