为什么Silverlight/WP7中的NavigationService使用字符串而不是类?

5

考虑到C#更偏向于强类型语言,为什么设计者选择基于URI的导航而不是基于类?

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

如果MyPage丢失,运行时将失败。

如果有一种支持将PhoneApplicationPage作为参数传递的方法,例如

NavigationService.Navigate(new MyPage()); 

导航相关的错误可以在编译时捕获。

为什么Silverlight/WP7中没有这种内在的设计呢?

5个回答

3
只有WP7开发工具团队能够确定,但在没有他们的参与下,我会尽力而为。我的猜测是,这源于使用插件框架进行客户端应用程序开发。Web Silverlight甚至没有真正的导航概念。您可以在应用程序的主框架中切换帧,但那并不是真正的导航。因此,当被要求将Silverlight用作WP7的客户端应用程序工具时,他们必须决定如何进行导航。
如果您是一个一直在构建互联网应用程序的团队,最明显解决导航问题的方法就是使其尽可能接近互联网模型。这使得开发人员可以将互联网应用程序带到浏览器中,并对其代码进行最小化重写。想象一下,如果您有一个Web应用程序,该应用程序使用相对URL在应用程序页面之间移动,那么您的WP7可以仅稍微修改以使用新的NavigationService即可重复使用大部分导航逻辑。这也最小化了WP7版本必须进行的核心Silverlight更改,使所有内容易于在平台之间保持同步。
显然这不是做事情的最佳方式,并且它使得页面之间的状态维护变得十分麻烦,但我至少可以看到他们为什么要以这种方式做出决定。在我的经验中,主要的缺陷是导航目的地的运行时检查(而不是使用类进行编译时检查),传递参数(每个页面都需要一个OnNavigatedTo来解析变量)以及在页面之间维护非平凡对象(我已经开始使用单例来保存相关对象作为一种贫民窟缓存)。我希望在7.5或8中至少对导航范例进行一些修改,但我不抱太大希望。

1

1

1

这个导航模型是从桌面版的Silverlight(以及之前的WPF)继承而来的。需要注意的是:这不是基于字符串的模型,而是基于URI的模型。这里的区别非常关键:我们不是在谈论一个任意的字符串来指向某个XAML,而是在谈论一个通用的资源定位符,它是应用程序中的一个页面。通过这种方式处理导航,你的应用程序实际上有多个入口点——应用程序中的任何URI都可以成为有效的入口点。通过使导航基于URI,你可以确保与你正在查看的内容相关的应用程序“状态”可以被序列化、从任何方向随时访问等。

例如,假设您在网页(或电子邮件或任何其他地方)上有一个链接,您想要在应用程序中打开它。单击该链接,因为URI完全描述了应用程序应显示的资源(例如目录中的项目,搜索过滤器等),因此您可以直接跳转到它(也称为深度链接)。这在Windows Phone 7上没有实现(至少不是从其他应用程序,但这确实是后退按钮等的工作方式),但该模型直接来自桌面上的Silverlight(导航框架在Silverlight SDK中),您可以看到他们将来可能在Windows Phone上采取什么措施。
同样,URI的强大之处在于其普遍性-它是识别资源的常见方法。如果没有它,您将被困在任何想要导航到您的应用程序并且应用程序本身之间的紧密耦合中。

0

此外请记住,使用框架,您可以使用 Silverlight 中的路由来将一个或多个用户友好的 URL 映射到同一个 .xaml 文件。 如果只指定视图类,则 Silverlight 将不知道要映射到哪个 URL。

传递查询参数进行状态管理可能有些丑陋,但它允许您的应用程序是无状态的,这具有一些优点(例如深链接),并符合 HTTP Web 应用程序的无状态特性。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接