データ バインディングと MVVM
Model-View-ViewModel (MVVM) は、UI と UI 以外のコードを分離するための UI アーキテクチャ デザイン パターンです。 MVVM では、XAML で宣言によって UI を定義し、データ バインディング マークアップを使用して、データとコマンドを含む他のレイヤーにそれをリンクします。 データ バインディング インフラストラクチャは、UI とリンクされたデータの同期を維持し、ユーザー入力を適切なコマンドにルーティングする疎結合を提供します。
疎結合を提供するため、データ バインディングの使用によって、さまざまな種類のコード間の強固な依存関係が減少します。 これにより、他のユニットで意図しない副作用が発生することなく、個々のコード ユニット (メソッド、クラス、コントロールなど) を簡単に変更できるようになります。 この分離は、多くのデザイン パターンでの重要な概念である懸念事項の分離の一例です。
MVVM の利点
コードの分離には、次のような多くの利点があります。
- 反復的な探索的コーディング スタイルが可能になる。 分離された変更はリスクが低いため、簡単に実験できる。
- 単体テストの簡略化。 相互に分離されたコード ユニットは、個別に、かつ運用環境の外部でテストできる。
- チーム コラボレーションのサポート。 適切に設計されたインターフェイスに準拠する分離されたコードを、各個人またはチームで開発し、後で統合できる。
- 保守性の向上。 分離されたコードでバグを修正することで、他のコードで回帰が発生する可能性が低くなる。
MVVM とは対照的に、従来の "分離コード" 構造を持つアプリでは、通常、表示専用データにデータ バインディングを使用し、コントロールによって公開されるイベントを直接処理してユーザー入力に応答します。 イベント ハンドラーは、分離コード ファイル (MainPage.xaml.cs など) に実装され、多くの場合、コントロールに厳密に結合されて、通常 UI を直接操作するコードを含んでいます。 これにより、イベント処理コードを更新しないと、コントロールを置き換えることが困難または不可能になります。 このアーキテクチャでは、分離コード ファイルによって、多くの場合に UI に直接関連しないコード (データベースアクセス コードなど) が蓄積され、最終的に、他のページで使用するために複製され、変更されることになります。
アプリ レイヤー
MVVM パターンを使用する場合、アプリは次のレイヤーに分割されます。
- モデル レイヤーは、ビジネス データを表す型を定義します。 これには、コア アプリ ドメインのモデル化に必要なすべてのものが含まれ、多くの場合、コア アプリ ロジックが含まれます。 このレイヤーは、ビューおよびビューモデル レイヤーから完全に独立しており、多くの場合、クラウドに部分的に配置されます。 モデル レイヤーが完全に実装されている場合、同じ基になるデータを操作する UWP や Web アプリなど、多数のさまざまなクライアント アプリを作成できます。
- ビュー レイヤーは、XAML マークアップを使用して UI を定義します。 マークアップには、特定の UI コンポーネントとさまざまなビューモデルおよびモデル メンバーとの間の接続を定義するデータ バインディング式 (x:Bindなど) が含まれます。 分離コード ファイルは、ビュー レイヤーの一部として使用され、UI をカスタマイズまたは操作するために、または作業を実行するビューモデル メソッドを呼び出す前に、イベント ハンドラー引数からデータを抽出するために必要な追加のコードを含むことがあります。
- ビューモデル レイヤーは、ビューにデータ バインディング ターゲットを提供します。 多くの場合、ビューモデルは、モデルを直接公開するか、特定のモデル メンバーをラップするメンバーを提供します。 ビューモデルでは、項目の一覧の表示順序など、モデルではなく UI に関連するデータを追跡するためのメンバーを定義することもできます。 さらにビューモデルは、データベースアクセス コードなどの他のサービスとの統合ポイントとしても機能します。 シンプルなプロジェクトでは、個別のモデル レイヤーは必要ありませんが、必要なすべてのデータをカプセル化するビューモデルのみが必要になる場合があります。
基本および高度な MVVM
どのようなデザイン パターンでも同様に、MVVM を実装する方法は複数あります。また、多くのさまざまな手法が MVVM の一部として考慮されます。 このため、UWP を含むさまざまな XAML ベースのプラットフォームをサポートするさまざまなサードパーティ製 MVVM フレームワークがあります。 ただし、これらのフレームワークには、通常、分離されたアーキテクチャを実装するための複数のサービスが含まれているため、MVVM の正確な定義がいくらかあいまいになります。
高度な MVVM フレームワークはきわめて便利な可能性がありますが、特にエンタープライズ規模のプロジェクトでは、特定のパターンや手法を採用することに関連したコストが発生します。また、プロジェクトの規模とサイズによっては、メリットが必ずしも明らかではありません。 幸い、明確で具体的なメリットが得られる手法だけを採用し、それ以外のものは必要になるまで無視することができます。
特に、データ バインディングの全能力を十分に理解して適用し、アプリのロジックを先述のレイヤーに分離するだけで、多くのメリットが得られます。 これは、Windows SDK によって提供される機能を使用するだけで、外部のフレームワークを使用することなく、実現できます。 特に、{x:Bind} マークアップ拡張を使用すると、以前の XAML プラットフォームよりもデータ バインディングが簡単になり、パフォーマンスが向上するため、以前に必要とされた大量の定型コードが不要になります。
基本的なすぐに使用できる MVVM の使用に関するその他のガイダンスについては、GitHub で顧客注文データベースのサンプルを確認してください。 その他の多くの UWP アプリのサンプルでも、基本的な MVVM アーキテクチャが使われており、トラフィック アプリのサンプルには、分離コードと MVVM の両方のバージョンが含まれており、MVVM 変換について説明するメモも含まれています。
関連項目
トピック
データ バインディングの詳細
{x:Bind} マークアップ拡張