Почему NavigationService в Silverlight / WP7 использует строки над классами?

Question

Учитывая, что C # больше ориентируется на строго типизированный язык, почему дизайнеры выбрали навигацию на основе URI вместо классов?

NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative)) 

не выполняется во время выполнения, если отсутствует MyPage.

Если существует метод, который поддерживает передачу PhoneApplicationPage в качестве аргумента, например

NavigationService.Navigate(new MyPage()); 

Ошибки, связанные с навигацией, могут быть обнаружены во время компиляции.

Почему это не было внутренним дизайном в Silverlight / WP7?

Answer 1

Только команда разработчиков WP7 может сказать наверняка, но без их участия я сделаю все возможное. Я предполагаю, что это происходит из-за использования плагина для разработки клиентских приложений. Web Silverlight даже не имеет концепции навигации. Вы можете переключать фреймы в основной фрейм приложения и из него, но это не совсем навигация. Поэтому, когда их попросили использовать Silverlight в качестве инструмента клиентского приложения для WP7, им пришлось решить, как они будут ориентироваться.

Самый очевидный способ решения проблемы навигации, если вы команда, которая занимается созданием интернет-приложений, - это сделать что-то максимально приближенное к интернет-модели. Это позволяет разработчикам переносить интернет-приложения в браузер и минимально переписывать их код. Подумайте об этом: если у вас есть веб-приложение, которое использует относительные URL-адреса для перемещения между страницами приложения, ваш WP7 может повторно использовать большую часть этой логики навигации с небольшими изменениями, чтобы использовать новый NavigationService. Это также сводит к минимуму изменения ядра Silverlight, которые должна сделать версия WP7, что упрощает синхронизацию между платформами.

Это, очевидно, не лучший способ сделать что-то, и это делает поддержание состояния между страницами королевской болью в заднице, но я могу по крайней мере увидеть , почему они решили сделать это таким образом. Основными недостатками, по моему опыту, являются проверка во время выполнения пунктов назначения навигации (вместо времени компиляции с классами), передача параметров (каждая страница требует OnNavigatedTo, который анализирует переменные) и обслуживание нетривиальных объектов между страницами ( просто использовать Singletons для хранения соответствующих объектов как своего рода кеш бедняков). Я надеюсь, что хоть какая-то модификация парадигмы навигации будет в 7.5 или 8, но я не задерживаю дыхание.

Answer 2

Эта модель навигации была унаследована от Silverlight на рабочем столе (и WPF до него).Важно отметить: это не модель на основе строк, а модель на основе URI.Разница здесь ключевая: мы не говорим о произвольной строке, указывающей на некоторый XAML, мы говорим об универсальном локаторе для ресурса, который является страницей в приложении.Обращаясь к навигации таким образом, ваше приложение фактически имеет более одной точки входа - любой URI в приложении может быть допустимой точкой входа.Создавая навигацию на основе URI, вы гарантируете, что «состояние» вашего приложения, связанное с тем, на что вы смотрите, может быть сериализовано, доступно в любое время с любого направления и т. Д.

Представьте себе,например, если у вас есть ссылка на веб-странице (или в электронном письме, или где-либо еще), которую вы хотите открыть в своем приложении.Нажмите на ссылку, и, поскольку URI полностью описывает ресурс, который должно отображать приложение (например, элемент в каталоге, фильтры поиска и т. Д.), Вы можете сразу перейти к нему (так называемая глубокая ссылка).Это не реализовано в Windows Phone 7 (по крайней мере, не из других приложений, но на самом деле работает кнопка «Назад» и т. Д.), Но модель поставляется прямо из Silverlight на рабочем столе (среда навигации находится в Silverlight SDK)и вы можете увидеть, где они могут взять его на Windows Phone в будущем.

Опять же, сила URI заключается в его универсальности - это распространенный способ идентификации ресурса.Без этого вы застряли в тесной связи всего, что хочет перейти в ваше приложение и само приложение.

Answer 3

В Caliburn Micro (платформа MVVM) у вас есть хороший способ обработки навигации с использованием только ViewModels - " экранов, проводников и композиции "

Answer 4

Во многих отношениях службы навигации Silverlight / WP7 не хватает, но существует достаточное количество платформ, позволяющих перейти к ViewModel / View. Некоторые примеры:

• Windows Phone MVP
• Колумб
• Ядро Xamling

Answer 5

Также следует помнить, что с помощью фреймов вы можете использовать маршрутизацию в Silverlight для сопоставления одного или нескольких удобных для пользователя URL-адресов с одним и тем же .xaml-файлом. Если вы укажете только класс представления, Silverlight не будет знать, с каким URL-адресом сопоставляться.

Передача параметров запроса для управления состоянием может быть уродливой, но она позволяет вашему приложению не иметь состояния, что имеет некоторые преимущества (например, глубокие ссылки) и соответствует природе веб-приложений http без состояния.