WPF/Silverlight VS WinRT

Я никогда не создавал приложение (и HelloWorld) в WinRT, и я очень подозрительный.

Мой вопрос в том, есть ли в WPF/Silverlight функции, которых нет в WinRT (исключая функции, которые по дизайну реализованы по-разному)?

И эти аспекты важны для меня и являются ядром моего вопроса, и в результате решение о том, следует ли начинать использовать WinRT или ждать, пока они будут реализованы для него:

Entity Framework?
WCF RIA?
Поддержка MVVM (Prism)
Различные инструментальные средства (Silverlight/WPF toolkit), которые предоставляют дополнительные элементы управления, такие как DatePicker и т.д.?

Мне не ясно, полностью ли WinRT нацелен на .NET или как он работает.

Кроме того, WinRT является клиентом (например, WPF) или может работать на удаленном клиенте, сидя на сервере (например, Silverlight)?

Еще один: как насчет обратной совместимости, если я разработаю приложение WinRT, сможет ли он когда-либо работать с Win XP?

Я все равно не понимаю, почему MVVM не интегрирован в линию и имеет бесшовную поддержку IDE, как у MVC. но это просто примечание. Я не могу использовать XAML без MVVM, любое приложение, которое немного больше, чем мир привет, легче сделать с MVVM.

Обновление после answer

Как я прокомментировал ответ, мне нравится дизайн WinRT, но вопрос остается нерешенным до тех пор, пока я не узнаю о конкретных технологиях, упомянутых выше (EF, WCF-RIA + Validation, MVVM, SDK и Toolkits). И, очевидно, я не собираюсь начинать продажи приложений WinRT или копаться в нем, пока у меня не будет указанных выше техников.

Заключение, поскольку тот, кто большую часть своей работы является LOB-приложениями, после проверки немного, HTML5 + JS далеко не является альтернативой SL. Поэтому для вывода я придерживаюсь SL и продолжаю рекомендовать его своим клиентам. SL занимает наименьшее время разработки и без ошибок. Javascript - это грязный язык, подверженный ошибкам, без рисунка и без орехов, по сравнению с С#.

Как только EF + RIA + Prism + Toolkits будут полностью поддерживаться для WinRT, я рассмотрю вопрос о том, чтобы мои приложения LOB были на метро.

Ответ 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). Я призываю всех, кто интересуется этим пространством, изучать опубликованные материалы и справочные приложения - там есть отличные вещи:)

Ответ 2

Обратите внимание, что WinRT нацелен на приложения Windows 8 Metro-style, а не обычные настольные приложения (Windows 7), разработанные с помощью WPF или Winforms. Приложения в стиле Metro будут распространяться только через Windows Store. Microsoft взимает 30% за приложения Windows Store. Разработчики получают 70%. Это тот же "налог", который обвиняет Apple. Забудьте о Silverlight для версии Internet Explorer в стиле Metro. Он НЕ поддерживает плагины. Помните, что Silverlight - это плагин. Настольная версия Internet Explorer поддерживает плагины, поэтому Silverlight.