我正在用 C#/XAML 托管代码为 Windows 8 编写我的第一个 WinRT 应用程序，显然我必须处理可能出现的不同大小和方向的 UI（FullScreenLandscape、FullScreenPortrait、Filled 和 Snapped）。
大多数人似乎建议通过 XAML 中的可视状态管理器处理 UI 更改，但是我更喜欢编写代码隐藏而不是 XAML，我想我会简单地处理 Current_SizeChanged 事件，每个状态都有一个 switch 语句.
我尝试了两种方法，似乎都对我有用（尽管 VSM 显然更有用——至少对我来说）。
有人能告诉我为什么我应该使用 VSM 而不是代码，或者我会得到什么好处？
这是一个很好的问题，在开始 WPF 和 WinRT 开发时肯定会进入我的脑海。多年来为 C# 项目编写代码后，开始在 Xaml 中构建 UI 逻辑似乎是一个奇怪的概念（这通常比 C# 多行，但也更具声明性）。
实际上（如果您不介意我说的话）我认为我们可以将您的问题抽象为“通过 C#/VB.net 在 Xaml 中编写 UI 代码有什么好处吗？”。
让我举个例子，在工作中，我在一个项目团队中，有几个开发人员和几个图形设计师。设计人员非常擅长布置 Xaml，并为应用程序创建一致的感觉（我不能说我会那么擅长） - 但在编写 Web 服务和数据访问时几乎不知道层 - 这是我们作为开发人员的工作。这应该是正确的吗？
好吧，每当你开始写很多东西时C#.net 中的 View/UI 相关逻辑，这可能会导致各种问题。设计人员一下子就不能专注于手头的 Xaml，必须跟上 OO 编程的步伐。在我们的项目中，这并不是什么大问题，因为设计师实际上是非常称职的开发人员（一定是我去年强迫他们理解的所有 UI 代码 :)）但我认为它归结为“工作描述级别的关注点分离。如果我们采用与 WPF 相关的范式，我认为数据绑定“引导”开发人员走上他们创建分离的道路，
所以，回到你的问题 - 不，我不认为有任何直接的好处，如果你来自主要的 .Net 背景来写很多这些东西，Xaml 可能有点棘手。但是，如果您在一个团队中 - 或者如果您发现最佳实践是开发中非常重要的因素，那么在 Xaml 中编写与视图相关的代码（例如视觉状态管理器配置）是不错的选择。
最后一点 - 你会注意到我经常使用术语“查看相关逻辑”。这是因为人们普遍认为，在代码隐藏中编写与 UI 相关的代码是可以接受的（如果不是最佳实践的话），但有时由于 WPF 或 WinRT 框架的性质，您会因为某些功能而被拖下这条路线。但是，如果您在代码隐藏的 UI 文件中编写业务逻辑，这将被视为一个特殊的禁忌。这打破了“关注点分离”，并使测试变得非常困难。如果您遵循 MVVM 模式（正如许多 WPF 或 WinRT 项目所做的那样），那么这就是 ViewModel 的职责。