Windows Phone 7：我应该添加新页面或更改网格的可见性以在不同表单之间切换吗？
我试图尽我所能地表达标题，但我想要实现的是，在 MainPage.xaml 上我有一个按钮，然后理想情况下我想转到 NewPage.xaml 。
现在这可能吗，或者我完全处于错误的波长上，如果是这样，有人可以指出我正确的方向吗？
I’ve tried to word the title the best I could but what I’m trying to achieve is that on the MainPage.xaml I have a button and then ideally I want to go to NewPage.xaml .
Now is this possible or I am completely on the wrong wave length and if so could someone point me in the right direction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最好使用导航服务导航到新页面，以便当用户按下“后退”按钮时，他们会自动返回到上一页（如预期）。
It's best to use the navigation service to navigate to a new page so that when the user presses the Back button they automatically get sent back to the previous page (as expected).
这实际上取决于你要做什么。 MSDN “Windows Phone 的应用程序页面模型”< /a> 页面很好地描述了何时适合使用不同的页面，何时不适合。
它通常涉及代表导航堆栈一部分的页面，理想情况下代表一些用户可识别的步骤（例如查看项目的详细信息，或者可能执行搜索）。我同意这并不总是明确的。
It depends on what you're going to do, really. The MSDN "Application Page Model For Windows Phone" page has a pretty good description of when it's appropriate to use a different page and when it's not.
It's generally about a page representing part of a navigation stack, ideally representing some user-identifiable step (e.g. looking at the details of an item, or possibly performing a search). I agree it's not always clearcut though.
这是我使用该框架还是解决我自己的问题之一。
通过使用该框架，您可以完成一些繁重的工作（例如后退键处理），但代价是保持在框架范围内。当平台考虑进行可能会破坏某些代码的更改时，您也更有可能考虑您的代码。
通过不使用该框架，您可以获得更大的灵活性，但代价是执行更多繁重的工作，并且可能会在未来的版本中破坏您的模型。您也更有可能遇到框架路径所满足的惊喜。
话虽如此，有些人一直在按照您的建议作为使用 NavigationService 的替代方案。他们遇到的障碍之一是复杂性。另一个是通过预先声明多个页面，页面负载会变得非常重。
Jon 为您指出的链接是一个很好的指南，Peter Torr 关于相关主题的帖子也是如此。
介绍“的概念”地点” - Peter Torr 的博客
This is one of those do I use the framework or go it on my own questions.
By going with the framework you get some heavy lifting done for you (such as back key handling) at the cost of staying within the frameworks boundaries. You're also more likely to have your code considered when the platform considers make changes that potentially break some code.
By not going with the framework you get greater flexibility at the cost of doing more heavy lifting and potentially having your model broken by future releases. You're also more likely to hit surprises that are catered for by the framework path.
With all that said, some people have been doing what you suggest as an alternative to using NavigationService. One of the walls they hit is complexity. The other is the page load gets very heavy by having multiple pages declared up front.
The link Jon pointed you to is a good guide, as is Peter Torr's post on a related topic.
Introducing the concept of “Places” - Peter Torr's Blog