Metro 风格应用 UI 设计：页面与场景
我正在开发一个 Windows 8 Metro 风格的应用程序，使用开发者预览版来完成大学的一个学术项目。我们必须使用MVVM模式。
在主页中，我们有一个带按钮的 Metro 风格主菜单。每个按钮都会指向一个应用程序工具（即“显示我的库”、“显示收藏夹”……），根据 MVVM 模式，该工具应该属于不同的视图。
您认为我们应该为每个视图创建一个新的“地铁风格页面”，还是为每个 提供一个“场景”用例刷新主页，就像许多示例应用程序中出现的那样？ 换句话说，使用 MVVM 是否应该在“普通旧 WPF Windows”和“全新 Metro 风格页面”之间进行 1:1 匹配？
I'm working on a windows 8 metro-style app, using developer preview for an academic project at university. We have to use MVVM pattern.
In the main Page we have a metro-style main menu with buttons. Each button leads to an application facility (ie. 'Show my Library', 'Show Favourites', ...) which should belong to a different View, according to MVVM pattern.
In your opinion should we create a new 'metro-style Page' for each View or expect a 'Scenario' for each use case refreshing the main Page, like those present in many example apps?
In other terms, using MVVM should there be a 1:1 match between 'plain old WPF Windows' and 'brand new metro-style Pages'?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MVVM 的问题在于，除了视图是用户查看 ViewModel 数据的方式这一事实之外，关于视图的构成没有硬性规则。
视图不必是页面，但可以是控件。因此，如果您愿意，您可以拥有一个页面，在该页面上显示许多视图控件。我经常将视图作为控件，即使它们是页面上显示的唯一项目，因为它允许我在以后更轻松地将它们嵌入到其他页面中。
MVVM 模式纯粹是一种将 UI 与业务/代码逻辑分离的方法。 ViewModel 类并不关心它的数据如何显示，它只是提供要显示的数据的绑定点、属性等以及代码功能的触发点。
有些人会坚持认为文件后面的代码中永远不会有任何代码，但我认为需要一种更务实的方法。控制视图视觉方面的代码很好，但有时会出现业务逻辑侵入的情况。
例如，在实现拖放功能时，后面的代码中将需要代码。这实际上只是一个视觉方面，所以没有问题，但如果业务模型规定仅将某些项目或最大数量的项目放置在给定位置，那么 ViewModel 将需要提供一些 View 可以使用的数据绑定点用于实现这一点。通过这样做，您可能会认为后面的视图代码现在实现了一些业务逻辑。
那么回到你原来的问题。我会尝试实现该应用程序，使其行为符合 Windows 8 Metro-stryle 应用程序的预期。这显然会影响您的编码方式，但在这样做时仍然可以坚持 MVVM 模式。
The thing with MVVM is that there are no hard rules as to what constitutes a View other than the fact that it is the means by which the user can view the ViewModel data.
A View need not be a Page, but can be a Control. Thus you can have one page, on which many View controls are displayed, if you wish. Quite often I have my Views as controls, even if they are to be the sole item displayed on a page, as it allows me to embed them in other pages more easily at a later date.
The MVVM pattern is purely a means of separating the UI from the business/code logic. A ViewModel class doesn't care how it's data is displayed, it just provides the binding points, properties etc., for the data to be displayed and trigger points for code function.
Some people will insist that there is never any code in the code behind files, but I think that a more pragmatic approach is required. Code that controls visual aspects of the View is fine, and there are occaisions when what appears to be business logic intrudes.
For example when implementing drag and drop functionality code will be required in the code behind. This is really just a visual aspect so no problem there, but if the business model dictates that only certain items, or a maximum number of items are dropped in a given location then the ViewModel will need to provide some data binding points that the View can use to implement this. By doing so you could argue that the View code behind now implements some business logic.
So back to your original question. I would try to implement the application such that it behaves as is expected for a windows 8 metro-stryle application. This will obviously have a bearing on how you code, but it should still be possible to stick to the MVVM pattern when doing so.