鉴于C＃更倾向于强类型语言，为什么设计师选择基于URI而不是类的导航？
NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative))
在运行时失败。
如果有一种方法支持将PhoneApplicationPage作为参数传递，如
NavigationService.Navigate(new MyPage());
导航相关错误可以在编译时捕获。
为什么这不是Silverlight / WP7中固有的设计？
答案 0 :(得分：3)
只有WP7开发工具团队可以肯定地说，但如果没有他们的意见，我会尽我所能。我的猜测是，它产生于使用插件框架进行客户端应用程序开发。 Web Silverlight甚至没有真正的导航概念。您可以切换进出应用程序主框架的框架，但这不是真正的导航持久性。因此，当他们被要求使用Silverlight作为WP7的客户端应用程序工具时，他们必须决定他们将如何导航。
解决导航问题最明显的方法是，如果你是一个正在构建互联网应用程序的团队，那就是尽可能地建立一个与互联网模型接近的东西。这允许开发人员将互联网应用程序传送到浏览器并对其代码进行最少的重写。想想看，如果你有一个使用相对URL在应用程序页面之间移动的Web应用程序，你的WP7可以重用大部分导航逻辑，只需稍加修改即可使用新的NavigationService。这也最大限度地减少了WP7版本必须进行的核心Silverlight的更改，使得在平台之间更容易保持同步。
它显然不是最好的做事方式，它使页面之间的状态维护成为屁股中的皇家痛苦，但我至少可以看到为什么他们决定这样做。根据我的经验，主要的缺陷是导航目的地的运行时检查（而不是使用类的编译时间），传递参数（每个页面需要一个OnNavigatedTo来解析变量）和维护页面之间的非平凡对象（我是仅仅使用Singletons来保存相关对象作为一种穷人的缓存）。我希望在7.5或8中至少对导航范例进行一些修改，但我并没有屏住呼吸。
答案 1 :(得分：1)
Silverlight / WP7导航服务在很多方面都相当缺乏，但是有相当多的框架允许您导航到ViewModel / View。一些例子：
答案 2 :(得分：1)
在Caliburn Micro（MVVM框架）中，您只使用ViewModels - “Screens, Conductors and Composition”
答案 3 :(得分：1)
此导航模型继承自桌面上的Silverlight（以及之前的WPF）。重要的是要注意：这是不基于字符串的模型，而是基于URI的模型。这里的区别是关键：我们不是在谈论一个指向某个XAML的任意字符串，我们讨论的是一个资源的通用定位器，它是应用程序中的一个页面。通过这种方式处理导航，您的应用程序实际上有多个入口点 - 应用程序中的任何URI都可以是有效的入口点。通过基于URI的导航，您可以确保应用程序的“状态”与您正在查看的内容相关，可以随时从任何方向进行序列化，访问等。
想象一下，例如，您要在应用程序中打开的网页（或电子邮件或其他任何地方）上有链接。单击该链接，因为URI完全描述了应用程序应显示的资源（例如，目录中的项目，搜索过滤器等），您可以直接跳转到它（a.k.a。深层链接）。这不是在Windows Phone 7上实现的（至少不是来自其他应用程序，但它实际上是后退按钮等的工作原理），但该模型直接来自桌面上的Silverlight（导航框架在Silverlight SDK中） ，您可以在将来看到他们在Windows Phone上的位置。
同样，URI的强大之处在于它的普遍性 - 它是识别资源的常用方法。没有它，你就会陷入想要导航到你的应用程序和应用程序本身的任何东西的紧密耦合。
答案 4 :(得分：0)
另请注意，使用框架可以在Silverlight中使用路由将一个或多个用户友好的URL映射到同一个.xaml文件。如果您只指定视图类，那么Silverlight将不知道要映射到哪个URL。
传递状态管理的查询参数可能很难看，但它允许您的应用程序是无状态的，它具有一些优点（例如深层链接）并且符合http Web应用程序的无状态特性。