为什么 Silverlight/WP7 上的 NavigationService 使用字符串而不是类？
鉴于 C# 更倾向于强类型语言，为什么设计者选择基于 URI 而不是类的导航？
NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative))
如果 MyPage 丢失，则会在运行时失败。
如果有一种方法支持将 PhoneApplicationPage 作为参数传递，例如
NavigationService.Navigate(new MyPage());
导航，则可以在编译时捕获相关错误。
为什么这不是 Silverlight/WP7 的固有设计？
Given that C# is a leans more towards a strongly typed language, why did the designers chose navigation based on URIs over Classes?
NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative))
fails at run time if MyPage is missing.
If there were a method that support passing a PhoneApplicationPage as a argument like
NavigationService.Navigate(new MyPage());
Navigation related errors can be caught at compile time.
Why was this not an inherent design in Silverlight/WP7 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
只有 WP7 开发工具团队可以肯定地说，但如果没有他们的意见，我会尽力而为。我的猜测是，它是由于使用插件框架进行客户端应用程序开发而产生的。 Web Silverlight 甚至没有真正的导航概念。您可以在应用程序主框架中切换框架，但这并不是真正的导航方式。因此，当他们被要求使用 Silverlight 作为 WP7 的客户端应用程序工具时，他们必须决定如何进行导航。
如果您是一个一直在构建互联网应用程序的团队，那么解决导航问题的最明显的方法就是制作尽可能接近互联网模型的东西。这使得开发人员可以将互联网应用程序移植到浏览器上，并对其代码进行最少的重写。想一想，如果您有一个使用相对 URL 在应用程序页面之间移动的 Web 应用程序，您的 WP7 可以重用大部分导航逻辑，只需稍作修改即可使用新的 NavigationService。这也最大限度地减少了 WP7 版本必须对 Silverlight 核心所做的更改，从而使一切更容易在平台之间保持同步。
这显然不是最好的做事方式，而且它使页面之间的状态维护成为一件令人头疼的事情，但我至少可以明白为什么他们决定这样做。根据我的经验，主要缺陷是导航目的地的运行时检查（而不是类的编译时）、传递参数（每个页面都需要一个解析变量的 OnNavieratedTo ）以及页面之间非平凡对象的维护（我已经采取仅使用单例来保存相关对象作为一种穷人的缓存）。我希望至少对 7.5 或 8 中的导航范例进行一些修改，但我并没有屏住呼吸。
Only the WP7 dev tools team can say for sure, but absent their input, I'll give it my best shot. My guess is that it arises out of using a plug-in framework for client application development. Web Silverlight doesn't even really have the concept of navigation. You can switch frames in and out of the applications main frame, but that's not really navigation persay. So, when they were asked to use Silverlight as a client application tool for WP7, they had to decide how they were going to navigate around.
The most obvious way to solve the navigation problem, if you're a team that's been building internet applications, is to make something as close to the internet model as possible. This allows developers to carry internet applications to the browser and do minimal rewrites of their code. Think about it, if you had a web application that used relative URLs to move between application pages, your WP7 could reuse most of that navigation logic with only slight modifications to use the new NavigationService. This also minimizes the changes from core Silverlight that the WP7 version has to make, making everything easier to keep synchronized between platforms.
It obviously isn't the best way of doing things, and it makes state maintenance between pages a royal pain in the ass, but I can at least see why they decided to do it this way. The main flaws, in my experience, are the runtime checking of navigation destinations (instead of compile time with classes), passing parameters (every page needs an OnNavigatedTo that parses out variables) and maintenance of non-trivial objects between pages (I've taken to just using Singletons to hold relevant objects as a sort of poor-man's cache). I'm hoping for at least some modification to the navigation paradigm in 7.5 or 8, but I'm not holding my breath.
此导航模型继承自桌面上的 Silverlight（以及之前的 WPF）。需要注意的是：这不是基于字符串的模型，而是基于 URI 的模型。这里的区别很关键：我们不是在谈论指向某个 XAML 的任意字符串，而是在谈论应用程序中的页面资源的通用定位器。通过以这种方式处理导航，您的应用程序实际上拥有多个入口点——应用程序中的任何 URI 都可以是有效的入口点。通过使导航基于 URI，您可以确保与您正在查看的内容相关的应用程序的“状态”可以被序列化、可以随时从任何方向访问等。
例如，想象一下，您有您想要在应用程序中打开的网页（或电子邮件或其他任何地方）上的链接。单击该链接，由于 URI 完整地描述了应用程序应显示的资源（例如目录中的项目、搜索过滤器等），因此您可以直接跳转到它（也称为深层链接）。这在 Windows Phone 7 上没有实现（至少其他应用程序没有实现，但这确实是后退按钮等的工作原理），但该模型直接来自桌面上的 Silverlight（导航框架位于 Silverlight SDK 中） ，您可以看到他们将来可能会在 Windows Phone 上使用它。
同样，URI 的强大之处在于它的通用性——它是识别资源的常用方法。如果没有它，您将陷入任何想要导航到您的应用程序和应用程序本身的紧密耦合。
This navigation model was inherited from Silverlight on the desktop (and WPF before it). It's important to note: this is not a String-based model, but rather a URI-based model. The difference here is key: we're not talking about an arbitrary string to point to some XAML, we're talking about a universal locator for a resource that is a page within the application. By addressing navigation this way, your application actually has more than one entry point -- any URI within the application can be a valid entry point. And by making navigation URI-based, you ensure that the "state" of your application as it relates to what you're looking at can be serialized, accessed at any time from any direction, etc.
Imagine, for example, that you have a link on a webpage (or in an email, or anywhere else) that you want to open in your application. Click the link, and because the URI fully describes the resource that the application should display (e.g. an item in a catalog, filters on a search, etc.), you can jump straight to it (a.k.a. deep-linking). This isn't implemented on Windows Phone 7 (at least not from other apps, but it's really how the back button, etc. work), but the model comes straight from Silverlight on the desktop (the Navigation framework is in the Silverlight SDK), and you can see where they might take it on Windows Phone in the future.
Again, the power of the URI is its universality -- it is a common way to identify a resource. Without it, you're stuck with a tight coupling of anything that wants to navigate into your application and the application itself.
Silverlight/WP7 导航服务在很多方面都相当缺乏，但是有相当多的框架允许您导航到 ViewModel/View。一些示例：
Silverlight/WP7 navigation service is fairly lacking in many regards, but there are a fair number of frameworks around that allow you to navigate to the ViewModel/View. Some examples:
在 Caliburn Micro（MVVM 框架）中，您有一种仅使用
ViewModels- "屏幕、导体和组合 ”In Caliburn Micro (MVVM framework) you have a nice way of handling navigation using only
ViewModels- "Screens, Conductors and Composition"另请记住，使用框架，您可以在 Silverlight 中使用路由将一个或多个用户友好的 URL 映射到同一 .xaml 文件。如果您只指定视图类，那么 Silverlight 将不知道要映射到哪个 URL。
传递状态管理的查询参数可能很丑陋，但它允许您的应用程序是无状态的，这有一些优点（例如深层链接）并且适合 http Web 应用程序的无状态性质。
Also keep in mind that using frames you can use routing in Silverlight to map one or more user-friendly URLs to the same .xaml file. If you would specify only the view class then Silverlight wouldn't know to which URL to map to.
Passing query parameters for state managment might be ugly, but it allows your application to be stateless which has some advantages (e.g. deep links) and fits the stateless nature of http web applications.