0

適切なビューの作成を必要とするイベントが Model と ViewModel で発生します。問題は、これを行う方法と、VM または M に View コードが含まれないようにする方法です。

このジレンマを理解できるように、一連のイベントを次に示します。

ユーザーは、フォームに数値フィールドを設定して長時間実行されるバックグラウンド プロセスを開始し、[開始] ボタンをクリックします。この長時間実行されるプロセスが成功した場合は、結果を表示するグラフを含むチャートをポップアップする必要があります。ただし、何らかの理由でデータの処理に失敗した場合は、グラフをポップアップできず、代わりにフォームのテキスト ボックスに表示されるエラー メッセージをログに記録します。

現在、その開始ボタンは、実際にバックグラウンド スレッドを開始する ViewModel のメソッドを呼び出します。

ビューをいつ作成するか、または作成するかどうかを決定できるのは背景だけです。

現在、ChartInterface というインターフェイスを使用してこれを機能させています。ビューはこのインターフェイスを実装し、コールバック デリゲートをバックエンド モデルまで設定します。チャートの作成を決定すると、コールバックが呼び出され、インターフェイスを使用して適切なデータなどが渡されます。

ただし、数十または数百のグラフが作成される可能性があるため、これには問題があります。そのため、ユーザーが表示するグラフを選択できるように、すべてのグラフのリストを含む「ダッシュボード」が必要です。

そのため、バックエンドはダッシュボード ビューをいつ作成するか、作成するかどうかを決定し、それにチャート ビューを追加する必要があります。

ビューが必要なモデルがたくさんあるため、これらの状況がますます多くなり、大量のコールバックデリゲートを作成するのが非常に速くなるため、混乱が生じています。

多数のコールバックの代わりに単純化されているように見えるアイデアは、ViewBinder へのインターフェイスのみをバックエンドに渡すことです。次に、モデル オブジェクトを作成するたびに、それを ViewBinder に渡して、ビュー オブジェクトをバインドするかどうかを確認します。

私たちの考えでは、ほとんどのバックエンド オブジェクトは (最終的には) グラフィカルに監視するのに興味深いものになるでしょう。そのため、構築後にそれらのすべてが ViewBinder インターフェイスに渡された場合、ビューはそれに何かをバインドするかどうかを決定できます。

これは常に良い音です。

4

1 に答える 1

0

コードの作業中に答えが明らかになりました。

public interface ModelBinderInterface { void TryBind( オブジェクト モデル); }

1 つのグローバルな「サーバー ロケーター」の代わりに、すべてのビュー オブジェクトがこのインターフェイスを実装する方が自然です。

次に、ViewModel オブジェクトを作成するときに、それ自体を viewModel オブジェクトの ModelBinder プロパティに割り当てます。

これで、ViewModel はこの同じインターフェイスをバックエンド プロセスに渡すことができます。

関連するモデルがインスタンス化されるたびに、オブジェクトを使用して ModelBinder が呼び出されます。

次に、View オブジェクトは、オブジェクトをインスタンス化できるかどうかを判断できます。インスタンス化できない場合は、ModelBinderInterface も実装している親に呼び出しを渡すことができます。

このようにして、各ビューは、コントロールを DataGridView に追加するか、オブジェクトを ListView にバインドするかなどを理解するインスタンス化ビューを処理できます。

もちろん、これでもシングルトン ModelBinder が可能です。これは、下位レベルが、1 つしかないトップ レベル アプリケーション ModelBinder への呼び出しを処理し続けることができ、シングルトン インスタンスを提供できるためです。

于 2013-02-22T18:53:12.883 に答える