我正在用C#/XAML托管代码为Windows 8编写我的第一个WinRT应用程序，显然我必须处理可能出现的不同大小和方向的UI(FullScreenLandscape、FullScreenPortrait、Filled和Snapped)。
大多数人似乎建议通过XAML中的Visual State Manager来处理UI更改，但我更喜欢在后面编写代码，而不是XAML，我想我只需要为每个状态使用switch语句来处理Current_SizeChanged事件。
我尝试了两种方法，似乎都对我有效(尽管VSM显然更有效——至少对我来说是这样)。
有人能告诉我为什么我应该使用VSM而不是代码，或者我会得到什么好处吗？
这是一个很好的问题，当然也是我在开始WPF&WinRT开发。在编写C#项目多年后，开始在Xaml中构建UI逻辑似乎是一个奇怪的概念(它通常比C#多行，但也更具声明性)。
事实上(如果你不介意我说的话)我认为我们可以把你的问题抽象为"在C#/VB.net上用Xaml编写UI代码有什么好处吗？"。
让我举一个例子，在工作中，我在一个项目团队中，有几个开发人员和几个平面设计师。设计人员非常擅长部署Xaml，并为应用程序创造一致的感觉(我不能说我会那么擅长)，但在编写web服务和数据访问层时，他们几乎没有什么想法，这是我们作为开发人员的工作。这应该是正确的吗？
好吧，每当你开始在C#.net中编写很多与View/UI相关的逻辑时，这都会导致各种各样的问题。突然之间，设计人员无法专注于手头的Xaml，必须加快OO编程的速度。在我们的项目中，这并不是一个很大的问题，因为设计师实际上是非常有能力的开发人员(一定是我去年强迫他们理解的所有UI代码：)。但我认为这可以归结为工作描述级别的"关注点分离"。如果我们采用与WPF相关的范式，我认为像Databinding这样的东西会"引导"开发人员创建分离的、可测试的UI和业务层，就像Xaml的本质允许使用一种非常声明性的方法来编写UI一样，在这种方法中，视图逻辑是以非常可读的方式创建和维护的，而不会过多地了解OO编程的本质。
所以，回到你的问题上来-不，我不认为有任何直接的好处，如果你主要来自.Net背景，写很多这样的东西，Xaml可能会有点棘手。但是，如果您是一个团队成员，或者您发现最佳实践是开发中一个非常重要的因素，那么在Xaml中编写与视图相关的代码(如Visual State manager配置)是可行的。
最后一点——你会注意到我经常使用术语"视图相关逻辑"。这是因为人们普遍认为，在代码隐藏中编写UI相关的代码是可以接受的(如果不是最佳实践的话)，但有时由于WPF或WinRT框架的性质，您会因为某些功能而被拖下这条路。但是，如果您在UI文件代码行中编写业务逻辑，则会认为这是一个特定的"否"。这打破了"关注点分离"，可能会使测试变得非常困难。如果您遵循MVVM模式(就像许多WPF或WinRT项目一样)，那么这就是ViewModel的职责所在。