鑑於C＃更傾向於強類型語言，爲什麼設計人員選擇基於類的URI進行導航？爲什麼Silverlight/WP7上的NavigationService在類上使用字符串？
NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative))
如果MyPage丟失，則在運行時失敗。
如果有跡象表明支持傳遞的PhoneApplicationPage作爲論據像
NavigationService.Navigate(new MyPage());
導航相關的錯誤可以在編譯時被捕獲的方法。
爲什麼這不是Silverlight/WP7中的固有設計？
此導航模型是從桌面上的Silverlight（以及之前的WPF）繼承而來的。需要注意的是：這是而不是基於字符串的模型，而是基於URI的模型。這裏的區別很關鍵：我們不是在談論一個任意字符串指向某個XAML，我們正在討論一個資源的通用定位器，該資源是應用程序中的頁面。通過以這種方式處理導航，您的應用程序實際上具有多個入口點 - 應用程序中的任何URI都可以成爲有效的入口點。通過製作基於URI的導航，您可以確保應用程序的「狀態」與您所看到的內容相關，可以序列化，可以隨時從任何方向訪問等。
想象一下，例如，您在應用程序中打開的網頁（或電子郵件或其他任何地方）上有鏈接。點擊鏈接，並且因爲URI完整地描述了應用程序應該顯示的資源（例如，目錄中的項目，搜索過濾器等），所以可以直接跳到它（又名深度鏈接）。這不是在Windows Phone 7上實現的（至少不是其他應用程序，但實際上它是如何工作的），但該模型直接來自桌面上的Silverlight（導航框架位於Silverlight SDK中） ，你可以看到他們將來可以在Windows Phone上使用它。
同樣，URI的威力在於它的普遍性 - 它是識別資源的常用方法。沒有它，你就會陷入任何想要導入你的應用程序和應用程序本身的緊密耦合。
只有WP7開發工具團隊可以肯定地說，但如果沒有他們的意見，我會盡我所能。我的猜測是，它出於使用客戶端應用程序開發的插件框架。 Web Silverlight甚至沒有真正的導航概念。您可以切換進出應用程序主框架的幀，但這不是真正的導航。所以，當他們被要求使用Silverlight作爲WP7的客戶端應用工具時，他們必須決定他們將如何瀏覽。
解決導航問題最顯而易見的方法是，如果您是一個正在構建互聯網應用程序的團隊，則應儘可能地與互聯網模型儘可能接近。這使得開發人員可以將瀏覽器應用程序攜帶到瀏覽器，並對其代碼進行最低限度的重寫。想想看，如果你有一個Web應用程序使用相對URL在應用程序頁面之間移動，WP7可以重新使用大部分導航邏輯，只需稍作修改即可使用新的NavigationService。這也最大限度地減少了WP7版本所需的核心Silverlight變更，讓所有平臺之間的一切更容易保持同步。
這顯然不是做事情的最佳方式，它使得頁面間的狀態維護成爲屁股皇家的痛苦，但我至少可以看到爲什麼他們決定這樣做。根據我的經驗，主要缺陷是導航目標的運行時檢查（而不是編譯時間），傳遞參數（每個頁面需要一個解析變量的OnNavigatedTo）和維護頁面之間的非平凡對象（I've採取僅使用單身人士舉行相關的對象作爲一種窮人的緩存）。我希望在7.5或8中至少對導航範例進行一些修改，但我並沒有屏住呼吸。
Silverlight/WP7導航服務在許多方面都相當缺乏，但是有相當多的框架可以讓您導航到ViewModel/View。一些例子：
在Caliburn Micro（MVVM框架），你必須只ViewModels使用操作導航的好方法 - 「Screens, Conductors and Composition」
而且請記住，使用框架可以在Silverlight中使用路由來映射一個或多個u ser友好的URL到相同的.xaml文件。如果您只指定視圖類，則Silverlight將不知道要映射到哪個URL。
爲狀態管理傳遞查詢參數可能會很難看，但它允許您的應用程序是無狀態的，它有一些優點（例如深度鏈接）並適合http web應用程序的無狀態特性。