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