アプリケーションのあらゆる部分で使用するポップアップフォームを処理するための戦略を作成しようとしています。これまでの私の理解では、MainWindowのルートに単一のUserControl
が必要になるということです。これは、アプリ内で送信されるメッセージを処理する独自のViewModelにバインドされます。
私はMVVMLightを使用していますが、Messenger
クラスはかなり新しいです。
オブジェクトのリストがListBox
内に含まれているマスター/詳細シナリオを想像してみてください。これらの項目の1つを選択し、[編集]ボタンをクリックすると、画面全体をカバーするUserControl
が表示されます。次に、ユーザーは選択したアイテムを編集し、[OK]をクリックして変更をコミットできます。
開いたUserControl
を「汎用」にして、任意の(おそらくViewModel)をスローできるようにします... DataTemplate
を介してViewModelをレンダリングします。すべてのオブジェクトの変更を処理します。 [OK]をクリックすると、送信クラスにコールバックされ、以前と同じように変更が保持されます。
これが役立ついくつかの状況は...
誰かが私がこれを達成する方法のコードサンプルを提供できますか?
MVVMを使用してUIを設計する場合の目標は、Viewの懸念をViewModelの懸念から分離することです。理想的には、ViewModelはビューコンポーネントに依存しないようにする必要があります。ただし、これは理想的であり、MVVMのもう1つのルールは、必要に応じてアプリケーションを設計する必要があるということです。
ダイアログを表示するサービスを提供する領域では、2つの異なるアプローチが浮かんでいます。
どちらのアプローチも、サービスが提供する機能を定義するインターフェースに依存しています。次に、このサービスの実装がViewModelに注入されます。
また、どちらのアプローチにも特定の長所と短所がありますか。
別の可能な解決策は、メッセージングを使用してダイアログを表示することです。
使用しているアプローチが何であれ、IoC(制御の反転)パターンを使用してViewとViewModelを分離したままにする、つまり、さまざまな実装を使用できるようにインターフェイスを定義するようにしてください。サービスをViewModelにバインドするには、インジェクションを使用します。つまり、サービスをViewModelのコンストラクターに渡すか、プロパティを設定します。
最近、作成していたWPFアプリのMVVMの学習を開始しました。この 記事 をダイアログ表示の基礎として使用しました。サンプルプロジェクトをダウンロードすると、これは実際には非常に優れた分離メソッドであり、適切に抽象化されており、ビューを取得するには、ビューモデルのインスタンスを渡します。私はそれを自分の手段のためにいくらか拡張しました。標準のwin32MessageBoxはあいまいなので、警告やエラーなどにもWPFExtendedToolkitMessageBoxを使用しました。
動的フォームに関しては、ItemsControlを調査する必要があります。また、ViewModelには、ItemsControlをバインドするためにユーザーが編集する必要のあるデータアイテムのコレクションがあります。アクションのダイアログリストが完全に動的であるワークフローシステムデザイナに、アクションとそのパラメータを編集するためのダイアログがあります。これは、アイテムのコレクションをデータ型とともに公開することで行われたため、DataTemplateSelectorを使用して、正しいタイプのコントロールを含むDataTemplatesを選択できました。つまり、DateTimeのデータ型はDatePickerを示していました。
それが役立つことを願っています
その一般的なコードを「維持」するためにやってくる開発者の観点からは、それは苦痛のように聞こえます。あなたが説明したことから、フォームとダイアログに同じビューモデルを与え、表示したいダイアログ用の特定のXAMLテンプレートを作成します。