ホーム > コンピュータ > C# > WPF in C# > Prism

ベクトルドロー・レベルゼロ+

Prism Library 5.0 for WPFを使用してMVVMパターンを実装する 01[C# WPF Prism]

概要

MVVMパターン調べていて、Prismというツールキットを見つけました。MVVMパターンを使用するためのもっとも人気のあるツールキットのようです。

原文

訳文

Implementing the MVVM Pattern Using the Prism Library 5.0 for WPF(外部サイト)

パターンと実践 ディベロパー・センター

Microsoft Prism Library 5.0 for WPFの開発者のガイドから:

Model View ViewModel (MVVM)パターンは、あなたが、そのユーザー・インターフェイス(UI)から、 あなたのアプリケーションのビジネスとプレゼンテーション・ロジックを、明確に、分離することを支援します。 アプリケーション・ロジックとUIの間で明確な分離を継続することは、数多くの開発と設計の問題に対処するのに役立ちます。 そして、あなたのアプリケーションを、はるかに簡単に、テスト、保持、そして、発展できます。また、それは、コードを再利用する機会をはるかに改善することができます。 そして、開発者とUIデザイナーは、さらに簡単に共同作業することができます。アプリケーションの、それぞれの部品を開発するとき、

MVVMパターンを使用して、アプリケーションUIと根底にあるプレゼンテーションとビジネス・ロジックは、3つの分離したクラスに、分離されます。 :Viewは、UIとUIロジックをカプセル化します。; View Modelは、プレゼンテーション・ロジックと状態をカプセル化します。; そして、モデルは、アプリケーションのビジネス・ロジックとデータをカプセル化します。

]

Prismには、サンプルと参考になる実装が含まれています。 それは、Windows Presentation Foundation (WPF)アプリケーションで、MVVMパターンを実装する方法を紹介します。 また、Prismライブラリは、あなた独自のアプリケーションで、パターンを実装するのを助けることができる機能を提供します。 これらの機能は、MVVMパターンを実装するために、最も一般的な慣例を具体的に示します。 そして、テスタビリティをサポートし、Expression BlendとVisual Studioで、うまく動作するように設計されています。

この項目は、MVVMパターンの概要を提供し、その基本的な特徴を実装する方法を説明します。 高度なMVVMの筋書きの項目は、Prismライブラリを使用して、さらに進化したMVVMの筋書きを、どのように実装するかを説明します。

クラスの責任と特徴

Class Responsibilities and Characteristics

MVVMパターンは、中心となるWPF機能の一部を活用するために最適化された、データ結合、データテンプレート、コマンドと動作のような、 プレゼンテーション・モデル・パターンの密接なバリアントです。

MVVMパターンでは、Viewは、UIとどんなUIロジックでもカプセル化します。;View Modelは、プレゼンテーション・ロジックと状態をカプセル化します。; そして、Modelは、ビジネス・ロジックとデータをカプセル化します。ビューは、データ結合、コマンドと変更通知イベントを通じて、View Modelと相互作用します。 View Modelは、ビュー内の表示のために、必要に応じて、Model、変換、検証、そして、集約したデータに、問い合わせ、観察し、更新を調整します。

次の図は、3つのMVVMクラスとそれらの相互作用を示しています。

MVVMクラスとそれらの相互作用

MVVMクラスとそれらの相互作用

すべての分離されたプレゼンテーション・パターンのように、効果的にMVVMパターンを使用するための鍵は、 あなたのアプリケーションのコードを、適切なクラスの要素として考慮するために、 そして、これらのクラスが、さまざまな筋書きで相互作用する方法を理解するには、適切な方法を理解することにあります。 次の項目では、MVVMパターンのクラスの各々の役割と特徴を説明します。

ビュー・クラス

The View Class

ビューの役割は、ユーザーが画面で見るものの、構造と外観を定義することです。 理想的には、ビューの分離コードには、InitializeComponentメソッドを呼び出すコンストラクタだけが含まれています。 場合によっては、分離コードが、複雑なアニメーションのような、あるいは、コードが、直接、ビューの一部の視覚的な要素を操作する必要があるとき、 Extensible Application Markup Language (XAML)で表現することが、難しい、あるいは、能率が悪い、視覚的な動作を実装する、 UIロジック・コードが含まれているかもしれません。あなたは、あなたが、ユニット・テストが必要となるビューに、どんな論理コードも配置してはいけません。 一般的に、ビューの分離コード内の論理コードは、方法を検証する、UIオートメーションを通して、テストされます。

WPFでは、ビューのデータ結合式は、そのデータ背景に対して評価されます。MVVMでは、ビューのデータの状況は、 View Modelに設定されます。View Modelは、ビューに、プロパティとコマンドの実装を結びつけ、 そして、変更通知イベントを通して、状態のどんな変更でもビューに通知します。 一般的に、ビューとそのView Modelの間に、1対1のリレーションシップがあります。

一般的に、ビューは、コントロールから派生した、あるいは、UserControlから派生したクラスです。 しかしながら、場合によっては、データテンプレートで表されるビューが表示されるとき、 それは、オブジェクトを、視覚的に示すために使用されるUI要素を指定します。データテンプレートを使用して、 ビジュアル・デザイナーは、View Modelが、どのようにレンダリングされるかについて、簡単に指定することができます。 あるいは、基盤となるオブジェクト自体、あるいは、それを表示するために使用されるコントロールの動作を変更することなく、 その既定の視覚的な表現を修正することができます。

データテンプレートは、少しの分離コードも持っていない、ビューと考えることができます。 それらは、UIで表示することを要求されるたびに、特定のView Model型と結合するように設計されています。 実行時に、データテンプレートによって定義されるビューは、自動的にインスタンスを生成され、 対応するView Modelに、そのデータ・コンテクストを設定されるでしょう。

WPFでは、あなたは、アプリケーション階層で、View Model型とデータテンプレートを関連付けることができます。 WPFは、続いて、それらがUIで表示されるたびに、指定された型のどんなView Modelオブジェクトにでも、 自動的に、データテンプレートを適用するでしょう。これは、暗黙のデータ・テンプレートとして知られています。データ・テンプレートは、親ビューの外側で、 それ、あるいは、リソース・ディクショナリを使用する、コントロールと一緒に、インラインで定義することができます。 そして、宣言的に、ビューのリソース・ディクショナリに結合されます。

要約すると、ビューは、次に示す、重要な特徴を持っています。:

  • ビューは、ウィンドウ、ページ、ユーザー・コントロール、データテンプレートのような、視覚的な要素です。 ビューは、ビューとそれらの視覚的なレイアウトとスタイルに含まれるコントロールを定義します。
  • ビューは、そのDataContextプロパティを通して、View Modelを参照します。 ビューのコントロールは、プロパティへのデータ結合とView Modelで公開される命令です。
  • ビューは、ビューとView Modelの間で、データ結合の動作をカスタマイズするかもしれません。 例えば、ビューは、UIで示されるデータをフォーマットするために、値コンバータを使用するかもしれません。 あるいは、それは、ユーザーに、追加の入力データ検証を提供するために、妥当性検証規則を使用するかもしれません。
  • ビューは、アニメーションや移行のような、UIの視覚的な動作を定義して、処理します。 それは、View Model内の状態変化から、あるいは、UIに対するユーザーの相互作用を通して、起動されるかもしれません。
  • ビューの分離コードは、視覚的な動作を実装するために、UIロジックを定義するかもしれません。 それは、XAMLで表すのが困難です。あるいは、それは、ビューで定義される特定のUIのコントロールに直接参照する必要があります。

View Modelクラス

The View Model Class

MVVMパターン内のView Modelは、プレゼンテーション・ロジックとビューのためのデータをカプセル化します。 それは、ビューの特定の実装や型について、ビューやどんな知識にも直接の参照を持っていません。 View Modelは、プロパティとコマンドを実装します。その、ビューは、変更通知イベントを通して、データ結合とどんな状態の変更でもビューに通知できます。 View Modelで提供されるプロパティと命令は、UIで提供される、機能を定義します。 しかし、ビューは、その機能が、どのようにレンダリングかを決定します。

ビュー・モデルは、どんなモデル・クラスでも、ビューの相互作用を調整する役割があります。 それは、必要です。一般的に、ビュー・モデルとモデル・クラスの間に、1対多の関係があります。 View Modelは、モデル・クラス・ディレクトリをビューに公開することを選択するかもしれません。 それで、ビュー内のそのコントロールは、それらにディレクトリをデータ結合することができます。 この場合、クラス設計する必要があるモデルは、データ結合、そして、関連した変更通知イベントをサポートしています。 この筋書きの詳細については、この項目の後にある、データ結合の項目を参照してください。

View Modelは、変換する、あるいは、モデル・データを操作するかもしれません。 それで、それは、ビューで、簡単に利用することができます。 View Modelは、特にビューをサポートするために、追加されたプロパティを定義するかもしれません。; これらのプロパティは、通常の(あるいは、追加することができない)モデルの一部でありません。 例えば、View Modelは、ビューが簡単に存在するために、2つのフィールドの値を結合するかもしれません。 あるいは、それは、最大の長さのフィールドのために、入力の残りの文字の数を計算するかもしれません。 また、View Modelは、データの整合性を確保するために、データ確認ロジックを実装するかもしれません。

また、View Modelは、論理状態を定義するかもしれません。ビューは、UIで外観の変更を提供するために、使用することができます。 ビューは、レイアウトやスタイル変更を定義するかもしれません。 それは、View Modelの状態を反射します。例えば、View Modelは、指示される状態を定義するかもしれません。 そのデータは、Webサービスに非同期で送信されています。 ビューは、ユーザーに、視覚的なフィードバックを提供するこの状態の間、アニメーションを表示することができます。

一般的に、View Modelは、UIで表示されることができる、命令や動作を定義し、そして、ユーザーは、それを呼び出すことができます。 一般的な例は、View Modelが、Submitコマンドを提供するとき、それは、ユーザーが、Webサービス、あるいは、データリポジトリに、データを送信することができます。 ビューは、ボタンで、その命令を表示することを選択をするかもしれません。ユーザーが、データを送信するために、ボタンをクリックすることができるように、 一般的に、コマンドが利用できなくなるとき、その関連するUIの表示は無効にされます。 コマンドは、UIのそれらの外観の表示から、きれいにそれらを分離するために、ユーザーの動作をカプセル化する方法を提供します。

要約すると、View Modelには次の重要な特性があります:

  • View Modelは、非ビジュアル・クラスです。そして、WPFのどんな基底クラスからも派生しません。 それは、アプリケーションで、使用事例、あるいは、ユーザー・タスクをサポートするために、 要求されるプレゼンテーション・ロジックをカプセル化します。 View Modelは、ビューとモデルと独立し、テストしやすいです。
  • View Modelは、一般的に、直接、ビューを参照しません。ビューは、プロパティと命令を実装しデータ結合できます。 それは、変更通知イベントを通して、どんな状態の変更でも、 INotifyPropertyChangedとINotifyCollectionChangedインターフェイスを通じて、ビューに通知します。
  • View Modelは、ビューの相互作用をモデルと調整します。それが、ビューとモデルに存在しないかもしれない 、実装されるかもしれない追加されたプロパティによって、簡単に利用することができるように、データを変換する、あるいは、操作するかもしれません。 また、それは、IDataErrorInfoやINotifyDataErrorInfoインターフェイスを通して、データ検証を実装するかもしれません。
  • View Modelは、ビューが、ユーザーに視覚的に表示することができる論理状態を、定義するかもしれません。

備考

ビュー、あるいは、View model?

何度も、特定の機能が発見される場所は、明らかにしないで実装する必要があります。 一般的な目安は以下の通りです:UIの画面上での特定の視覚的な外観に関係している何かは、 後で、スタイルを更新することができます。(たとえ、あなたが、現在、スタイルを更新する予定がないとしても)ビューの中に、入れる必要があります。; どんなものでも、アプリケーションの論理的な動作は、View Modelに行く必要があることは重要です。 加えて、なぜなら、View Modelは、ビュー内の特定の視覚的な要素の明確な知識を持っていてはいけません。 ビューの中で視覚的な要素をプログラム上で操作するコードは、ビューの分離コードに存在する、あるいは、動作にカプセル化する必要があります。 同様に、データ項目を取り出したり、操作するコードは、View Modelの中に存在する必要があるデータ結合を通じて、ビューの中で、表示されています。

例えば、リスト・ボックスで選択した項目の強調表示色は、ビューで定義する必要があります。 しかし、表示するための項目のリスト、そして、選択した項目それ自身への参照は、View Modelで定義する必要があります。

Modelクラス

The Model Class

MVVMパターン内のモデルは、ビジネス・ロジックとデータをカプセル化します。 ビジネス・ロジックは、どんなアプリケーション・ロジックでも、同じように定義されます。 それは、アプリケーションデータの検索と管理、そして、データの整合性と妥当性検証を確実に強要する、 どんなビジネス・ルールでも確実に作成することに関係します。 再使用の機会を最大にするために、モデルは、どんな使用事例も含むべきではありません。 -具体的な、あるいは、ユーザー・タスク-具体的な動作、あるいは、アプリケーション・ロジック。

一般的に、モデルは、アプリケーションのクライアント側のドメインモデルを表示します。 それは、アプリケーションのデータモデルに基づくデータ構造を定義し、そして、ビジネスと妥当性検証論理を何でもサポートします。 また、モデルは、データアクセスとキャッシュをサポートするための、コードが含まれているかもしれません。 しかし、一般的に、別々のデータリポジトリやサービスは、このために使用されます。 多くの場合、ADO.NET Entity Framework、WCFデータサービス、WCF RIAサービスのような、 モデルとデータアクセス層は、データアクセスやサービス戦略の一部として作成されます。

一般的に、モデルは、機能を実装します。ビューに結合することが容易になります。 これは、通常、それが、INotifyPropertyChangedとINotifyCollectionChangedインターフェイスを通して、 プロパティと変更が通知されたコレクションをサポートすることを示しています。 一般的に、オブジェクトのコレクションを示すモデル・クラスは、ObservableCollectionクラスから派生します。 それは、INotifyCollectionChangedインターフェイスの実装を提供します。

一般的に、モデルは、機能を実装します。ビューに結合することが容易になります。 これは、通常、それが、INotifyPropertyChangedとINotifyCollectionChangedインターフェイスを通して、 プロパティと変更が通知されたコレクションをサポートすることを示しています。 一般的に、オブジェクトのコレクションを示すモデル・クラスは、ObservableCollectionクラスから派生します。 それは、INotifyCollectionChangedインターフェイスの実装を提供します。

備考

あなたのモデル・クラスが、必要とするインターフェイスを実装しない場合、どうなるでしょうか?

時には、あなたは、INotifyPropertyChanged、INotifyCollectionChanged、IDataErrorInfoやINotifyDataErrorInfoインターフェースを実装していない、 モデル・オブジェクトで動作する必要があります。それらの場合において、View Modelは、 モデル・オブジェクトを包み、そして、必要なプロパティをビューに公開する必要があるかもしれません。 これらのプロパティのための値は、モデル・オブジェクトによって、直接、提供されるでしょう。 View Modelは、プロパティのために、必要とされるインターフェイスを実装します。 それは、ビューが、簡単に、それらにデータ結合することができるように公開します。

モデルは、次に示す、重要な特性を持っています。:

  • Modelクラスは、アプリケーション・データとビジネス・ロジックをカプセル化する非ビジュアル・クラスです。 必要とされるビジネス・ルールとデータ検証ロジックをカプセル化することで、 それらは、アプリケーションのデータを管理するため、そして、その一貫性と妥当性を確実とするための役割を果たします。
  • モデル・クラスは、ビューやView Modelクラスを、直接、参照しません。 そして、それらが、どのように実装されるかについての依存関係を持っていません。
  • モデル・クラスは、一般的に、プロパティと変更通知コレクション・イベントを提供します。 INotifyPropertyChangedとINotifyCollectionChangedインターフェイスを通して、これは、それらを簡単に、ビューにデータを結びつけることができます。 一般的に、オブジェクトのコレクションを示すモデル・クラスは、ObservableCollection<T>クラスから派生します。
  • モデル・クラスは、IDataErrorInfoやINotifyDataErrorInfoインターフェイスのどちらかを通して、一般的に、データ検証とエラー報告を提供します。
  • モデル・クラスは、一般的に、データアクセスとキャッシュをカプセル化する、サービスやリポジトリーと一緒に使用されます。
Copyright (C) 2011-2016 kukekko All Rights Reserved.
kukekko@gmail.com
ご連絡の際はアドレスの@は半角にしてください。 また、お問い合わせページのURLの明記をお願いします。
「掲載内容は私自身の見解であり、所属する組織を代表するものではありません 」。
inserted by FC2 system