私は大きな要素を持っています。それが主要なコンポーネントであると想定することもできます。このコンポーネントには、私の場合は抽象パネルであるサブコンポーネントが含まれている必要があり、独自の MVP が既に実装されています。現在、MainComponent を実装しているため、小さな再利用可能な抽象サブコンポーネントの MVP を生成する必要があります。
私の質問は次のとおりです: 3 つのサブパーツのそれぞれをどこでスポーンする必要がありますか? ビューで表示し、プレゼンター + モデルでモデルを表示しますか? ビューで表示、プレゼンターでプレゼンター、モデルでモデル?
これについてのご意見をお寄せいただきありがとうございます。
MVP の特定の実装についてはあまり詳しく説明していませんが、この件に関する私の考えは次のとおりです。
独自の MVP が既に実装されている
これは、ビューがロードされたとき (メイン ビューまたはサブ ビュー) に、正しいプレゼンターとモデルが既に関連付けられていることを意味すると想定しています。また、サブ プレゼンターのいずれかがメイン プレゼンターとコンポーネントまたはサービスを共有している場合、これらは依存性注入フレームワークによって解決されると想定しています。
私の仮定が間違っている場合は、ビューのロードを担当するコンポーネントを更新して、これが確実に行われるようにする必要があります。つまり、ビューがロードされたときに機能します。
私の質問は次のとおりです: 3 つのサブパーツのそれぞれをどこでスポーンする必要がありますか? ビューで表示し、プレゼンター + モデルでモデルを表示しますか? ビューで表示、プレゼンターでプレゼンター、モデルでモデル?
上記の私のコメントによると、ビューをロードし、ビューが正しく構成されていることを確認するオブジェクトが必要です (このオブジェクトを と呼びましょうViewLoader)。このオブジェクトは、ビュー レイヤーから直接呼び出す必要があります。つまり、プレゼンターから呼び出すことはできません。
ただし、これの問題は、プレゼンター オブジェクトがアプリケーションを駆動するため、ビュー レイヤーに別のビューを読み込むように指示する方法が必要になることです。ビュー参照をプレゼンターに渡すことで、この問題を解決できます。ビュー参照は、使用されているビュー テクノロジに関する詳細を公開しないインターフェイスの背後に隠されている必要があります。次に例を示します。
public interface IMainView
{
void OpenSettings();
}
その後、プレゼンターはOpenSettings()メソッドを呼び出すことができます。メソッドは具体的なビュー クラスによって実装され、次のようになります。
public class MainView : UserControl, IMainView
{
public void OpenSettings()
{
var settingsView = viewLoader.Load(typeof(settingsView));
this.tabControl.add(settingsView);
}
}
インターフェイスを実装する実際の具象ビューは、 を使用しViewLoaderてビューをロードできるため、ビュー階層にビューを挿入することだけに関係する必要があることに注意してください (ViewLoaderが完全に構成されたビューを提供しているため)。
また、インターフェースは実際の実装ではなく、アプリケーションの動作を記述していることにも注意してくださいIMainView(つまり、OpenSettingsではなく名前が付けられていOpenDialogます)。これは、ビューが設定ビューを開く方法を変更した場合 (ダイアログ ボックスに表示するなど)、ビューのみを更新する必要があることを意味します。OpenSettings()プレゼンターは、メソッドを呼び出して目的の動作を呼び出すため、まったく変更する必要はありません。
要約すれば：