我正在开发一个 Windows 8 Metro 风格的应用程序，在大学的学术项目中使用开发者预览版。我们必须使用 MVVM 模式。
在主页中，我们有一个带有按钮的 Metro 风格主菜单。根据 MVVM 模式，每个按钮都指向一个应用程序工具(即“显示我的库”、“显示收藏夹”……)，它应该属于不同的 View 。
在您看来，我们应该为每个 View 创建一个新的“metro 风格页面”还是期望为每个 use case 提供一个“场景”？刷新主页，就像许多示例应用程序中出现的那样？
换句话说，使用 MVVM 是否应该在“plain old WPF Windows”和“brand new metro-style Pages”之间进行 1:1 匹配？
最佳答案
MVVM 的问题在于，除了它是用户可以查看 ViewModel 数据的方式之外，对于什么构成 View 没有硬性规定。
View 不必是页面，但可以是控件。因此，如果您愿意，您可以拥有一个页面，在该页面上显示许多 View 控件。我经常将我的 View 作为控件，即使它们是页面上显示的唯一项目，因为它允许我在以后更轻松地将它们嵌入到其他页面中。
MVVM 模式纯粹是一种将 UI 与业务/代码逻辑分离的方法。 ViewModel 类并不关心它的数据如何显示，它只是为要显示的数据和代码功能的触发点提供绑定(bind)点、属性等。
有些人会坚持认为文件背后的代码中永远没有任何代码，但我认为需要一种更务实的方法。控制 View 的视觉方面的代码很好，并且当似乎是业务逻辑侵入时，有时会出现这种情况。
例如，在实现拖放功能时，后面的代码中将需要代码。这实际上只是一个视觉方面，所以那里没有问题，但是如果业务模型规定只有某些项目或最大数量的项目被放置在给定位置，那么 ViewModel 将需要提供一些 View 可以的数据绑定(bind)点用于实现这一点。通过这样做，您可能会认为背后的 View 代码现在实现了一些业务逻辑。
所以回到你原来的问题。我会尝试实现该应用程序，使其行为符合 Windows 8 Metro-stryle 应用程序的预期。这显然会影响您的编码方式，但在这样做时仍然应该坚持使用 MVVM 模式。
关于c# - Metro风格的应用UI设计: Pages vs Scenarios，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8135016/