Ответ 1
WinRT представляет собой, в основном, коллекцию COM-объектов, которые обертывают кучу Win32 API ', которые отображаются как сборки, совместимые с CLI.
Microsoft изменила свой компилятор С++, чтобы потреблять и генерировать метаданные ECMA 335 (т.е. CLI), а не более традиционные и (в основном) С++/Только COM-формат MIDL или lib. Microsoft также изменила свой механизм Javascript "Chakra", чтобы также потреблять и испускать метаданные CLI.
Это означает, что при таргетинге на WinRT, код Javascript и С++ вместе с языками .NET, конечно же, могут потреблять сборки, совместимые с CLI (например,.NET), и могут генерировать сборки, совместимые с CLI (т.е..NET).
Таким образом, можно написать код WinRT на С++, любой язык .NET(например, С#, VB.NET, F #, Iron * и т.д.) и в Javascript.
WinRT API будет очень хорошо знаком вам, если вы когда-либо писали какой-либо .NET-код. Команда Windows на самом деле обратилась за помощью и руководством команды разработчиков .NET Framework при разработке WinRT, поэтому те же руководящие принципы проектирования, которые руководствовались всей командой .NET Framework и большинством сообщества .NET в течение последних 11 лет, были применены к API WinRT.
WinRT, совершенно откровенно, красиво:)
Основным преимуществом WinRT является то, что он заменяет файлы System.IO, network, stream IO аналогичным API, но которые ТОЛЬКО поддерживают async IO. Это означает, что вы не сможете писать приложения, которые блокируют потоки, пока ожидают вызовы в файловую систему или внешние системы через сеть для возврата, если вы не предпримете явные шаги для этого.
Это ХОРОШЕЕ.
К счастью, новые функции async/await для С# v5 и VB.NET v.next, а также определенная поддержка С++ означают, что вам не нужно идти и принципиально изменять то, как вы пишете код в этом новом мире async - обычно вам просто нужно добавить ключевое слово "async" к сигнатурам методов, которые вызывают асинхронный API, а затем использовать ключевое слово "ожидание", префиксное для каждого вызова асинхронного API.
Я настоятельно рекомендую вам смотреть сессию Андерса Хейлсберга, которая должна сделать все это очень понятным. Пока вы там, я также рекомендую вам посмотреть несколько других сессий //BUILD, особенно Гарри Пирсон говорит об использовании WinRT с С# и VB.NET и сеанс Mads на Async Made Simple в С# и 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 и т.д.:
Вы можете найти здесь область поверхности API WinRT здесь несколько подробнее. Ниже перечислены базовый WCF API.
Обратите внимание, что Microsoft настоятельно рекомендует использовать сетевые coomms для связи между приложениями Metro и другими приложениями метро или настольными приложениями/службами на одном компьютере. Прочитайте этот вопрос SO и ответьте Кейт Грегори - она ссылается на видео, где этот сценарий подробно обсуждается.
Если вы хотите общаться с оффшорными сетевыми сервисами, то у вас есть множество вариантов, включая WCF, сокеты и т.д.
Относительно RIA: Microsoft в настоящее время говорит, что если вам нужны данные, вам нужно будет получить ее через службу, а не напрямую из БД. Там нет ADO.NET для Metro, и рекомендация состоит в том, чтобы обрабатывать данные через 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). Я призываю всех, кто интересуется этим пространством, изучать опубликованные материалы и справочные приложения - там есть отличные вещи:)