WinRT - это, в основном, коллекция COM-объектов, которые обертывают множество Win32 API ', представленных как CLI-совместимые сборки.
Microsoft изменила свой компилятор C ++, чтобы использовать и генерировать ECMA 335 (т. Е. CLI) метаданные, а не более традиционные и (в основном) C ++ / COM-только форматы MIDL или lib файлов. Microsoft также изменила свой движок Javascript "Чакра", чтобы также использовать и выдавать метаданные CLI.
Это означает, что при нацеливании на код WinRT, Javascript и C ++ наряду с языками .NET, конечно, могут использовать CLI-совместимые (т. Е. .NET) сборки и могут генерировать CLI-совместимые (т. Е. .NET) сборки.
Таким образом, можно написать код WinRT на C ++, на любом языке .NET (например, C #, VB.NET, F #, Iron * и т. Д.) И на Javascript.
WinRT API будет ОЧЕНЬ знаком вам, если вы когда-либо писали какой-либо код .NET. Команда Windows фактически обратилась за помощью и руководством к команде разработчиков .NET Framework при разработке WinRT, поэтому к руководству всей команды .NET Framework и большей части сообщества .NET за последние 11 лет были применены те же рекомендации. WinRT API.
WinRT, откровенно говоря, красив:)
Основное влияние WinRT состоит в том, что он заменяет классы файлового, сетевого и потокового ввода-вывода System.IO аналогичными API-интерфейсами, но поддерживающими ТОЛЬКО асинхронный ввод-вывод. Это означает, что вы не сможете писать приложения, которые блокируют потоки, пока они ожидают возврата к файловой системе или внешним системам через сеть, если вы не предпримете явных шагов для этого.
Это ХОРОШО вещь.
К счастью, новые функции асинхронизации / ожидания в C # v5 и VB.NET v.next, а также специальная поддержка C ++ означают, что вам не нужно идти и кардинально менять способ написания кода в этом новом асинхронном мире - как правило, вам просто нужно добавить ключевое слово «async» в сигнатуры методов, которые вызывают асинхронные API, а затем использовать ключевое слово «await» с префиксом каждого вызова асинхронного API.
Я настоятельно рекомендую вам посмотреть Сессию Андерса Хейлсберга , которая должна прояснить все это. Пока вы там, я также призываю вас посмотреть несколько других сессий // BUILD, особенно доклад Гарри Пирсона об использовании WinRT с C # & VB.NET и сеанс Mads на Async Made Простой в C # и VB .
Я бы также порекомендовал вам взглянуть на улучшенную архитектуру платформы Win8 / WinRT , которую я опубликовал в блоге несколько недель назад и которая должна немного прояснить ситуацию.
Что касается самого .NET, как я сформулировал в своем посте выше, .NET не "уходит". Хотя некоторые из .NET API будут запрещены в приложениях WinRT (т. Е. Блокируют IO API), большинство API, от которых вы зависите, остаются и полностью доступны.
Относительно Silverlight: Silverlight - это плагин для браузера. Это измененное подмножество WPF и предлагает некоторые очень мощные и привлекательные функции. На самом деле настолько, что движок Silverlight XAML был перенесен в основную команду Windows и используется для большей части рендеринга Metro UI в Windows8 - даже самой ОС!
В итоге большая часть вашего кода Silverlight будет работать нормально, без каких-либо изменений , за исключением простого изменения нескольких «использующих» пространств имен.
Тонну сессий XAML из BUILD можно посмотреть здесь .
Что касается обратной совместимости, стремитесь к:
- По возможности, изолируйте код, который вы хотите использовать в WinRT, а также в настольных приложениях .NET, Windows Phone и т. Д., В переносные сборки.
- Абстрактный код, который должен принимать конкретные зависимости платформы и учитывать их ручную загрузку или использование IoC для объединения ваших модулей.
Честно говоря, я не думаю, что работа Microsoft состоит в том, чтобы писать каждую инфраструктуру для каждого сценария. Существует несколько подходов / рамок MVVP в дикой природе от разных людей с различными "за" и "против". А если вы не найдете его, создайте его, прикрепите на GITHub и станьте знаменитым;)
Но самое главное, что вам мало что мешает скачать и попробовать Win8 Consumer Preview и Dev11 Beta. Принеси их и попробуй - я думаю, ты найдешь их очень освежающими:)
НТН.
Обновление № 1 в ответ на конкретную поддержку EF, WCF и т. Д .:
Вы можете найти Площадь поверхности WinRT API, перечисленная здесь более подробно . основные API WCF перечислены здесь .
Обратите внимание, однако, что Microsoft настоятельно рекомендует не использовать сетевые комм-коды для связи между приложениями Metro и другими приложениями Metro или настольными приложениями / службами на одном компьютере. Прочитайте этот SO вопрос & ответ Кейт Грегори - она ссылается на видео, где этот сценарий обсуждается подробно.
Если вы хотите общаться с сетевыми службами вне сети, у вас есть широкий выбор вариантов, включая WCF, сокеты и т. Д.
Относительно RIA: Microsoft в настоящее время говорит, что если вам нужны данные, вам нужно получать их через службу, а не напрямую из БД. Для Metro нет ADO.NET, поэтому рекомендуется использовать данные через OData, JSON, XML / HTTP и т. Д. Данные как услуга - это в значительной степени сценарий RIA, поэтому я ожидаю, что RIA будет хорошо поддерживаться для приложений Metro. Вот сеанс BUILD на эту тему , который может пролить больше света.
Только вы можете сказать, поддерживаются ли ваши конкретные сценарии в WinRT. Я думаю, что вам лучше всего скачать кусочки и начать исследовать.
Обновление 2 после обновленной дорожной карты и руководства P & P:
P & P недавно опубликовала новую дорожную карту и руководство для создания приложений для Windows RT / Windows 8 "store" / "modern" LOB.
Данное руководство включает обновления для Prism / Kona , а также EntLib6 & Unity3 (IoC) . Я призываю всех, кто интересуется этим пространством, изучать опубликованные материалы и справочные приложения - там есть кое-что интересное:)