鉴于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应用程序的无状态特性。