Windows 8 用の最初の WinRT アプリを C#/XAML マネージ コードで作成していますが、発生する可能性のあるさまざまなサイズと方向 (FullScreenLandscape、FullScreenPortrait、Filled、Snapped) で UI を処理する必要があることは明らかです。
ほとんどの人は、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 でビュー/UI 関連のロジックを使用すると、あらゆる種類の問題が発生する可能性があります。設計者は突然、目の前の Xaml に集中できなくなり、OO プログラミングに慣れる必要があります。私たちのプロジェクトでは、デザイナーは実際には非常に有能な開発者であるため、これはそれほど問題ではありません (昨年、私が彼らに理解させたすべての UI コードだったに違いありません :)) しかし、要約すると、「職務記述書レベルでの懸念事項の分離。WPF に関連するパラダイムを取り上げると、データバインディングの「ガイド」開発者は、分離されたものを作成する道をたどると思います。
それで、あなたの質問に戻ります-いいえ、私はすぐに利益があるとは思いません。主に.Netのバックグラウンドから来て、これらのことをたくさん書く場合、Xamlは少しトリッキーになる可能性があります. ただし、チームに所属している場合、または開発においてベスト プラクティスが非常に重要な要素であることがわかっている場合は、Xaml で Visual State manager の構成などのビュー関連のコードを記述することをお勧めします。
最後にもう 1 つ、「関連するロジックを表示する」という用語を多用していることにお気付きでしょう。これは、コード ビハインドでUI 関連のコードを記述することは (ベスト プラクティスではないにしても) 許容されると広く見なされているためですが、WPF または WinRT フレームワークの性質により、一部の機能についてこのルートに引きずり込まれることがあります。ただし、UI ファイルのコード ビハインドでビジネス ロジックを記述している場合、これは特定の禁止事項と見なされます。これは「関心の分離」を壊し、テストを非常に困難にする可能性があります。MVVM パターンに従っている場合 (多くの WPF または WinRT プロジェクトがそうであるように)、これが ViewModel の役割です。