MVVM/MVPモデルに関するいくつかの考え方と、フレームワーク/レイヤーの残りの部分とのトライアド通信の仕方を考えてみましょう。最初のMVP(またはMVVM)とフレームワークの通信を確認します
私の質問は今や少し異なります。プレゼンターがフレームワークについて知りたくない場合は、フレームワークで作成したプレゼンターと何をするべきかを知りたいのですが?
単純な例:私たちがGUIについて話しているのはおそらく簡単ではないので、私のMVVM(または何でも)がゲームのエンティティをモデル化しているとしましょう。
ビュー(エンティティのグラフィック表示)、モデル(エネルギーなど)、プレゼンター(何か起こったときの対応方法)があります。
ここで、ゲームエンティティ間の通信を管理するMediatorがあり、作成されているすべてのゲームエンティティを知りたいとします。
この問題を解決するために私が見ることができる唯一の方法は、発表者にメディエーターについてDIを知らせ、プレゼンターがフレームワークメディエーターに自身を登録させることです。
私はむしろ、フレームワークに新しく作成されたプレゼンターについて知らせ、それをメディエーター(これはIoCの原則であるべき)に登録することを好むので、発表者にメディエーターについて知らせることは避けたいと思います。
これは、ビューの最初のアプローチを使用して可能なことですか?
ありがとうございました。
こんにちは、ありがとうございました!私は新しいフレームワークを発明したくなかったし、実際に依存関係を配線するためにIoCコンテナを使用することも望んでいなかった。問題はより「哲学」の問題であり、それが混乱を招く可能性があります。別の例を挙げようとします。 IoCはハリウッドの原則を教えていますよね?今、プレゼンターがサービスなどを使用するためにフレームワークの依存関係を知っていなければならない場合、それはもはやハリウッドの原則に従わない。だから私はHの原則を適用するためにプレゼンターをフレームワークに注入することが今まで考えられているのだろうかと思っていました。 – sebas
申し訳ありませんが、私の喧嘩のために、私はちょうど私の混乱の原因になる可能性があることを認識しました。これまでは、ViewModelはビュー自体で作成されていたはずで、代わりに通常はいくつかのメカニズム(IoCコンテナ、DI、ServiceLocator)を介して配線されていると考えました。これは、実際には、ビューモデルを作成するビューの責任ではないことを意味し、したがって、ビューモデルはフレームワーク自体によって作成される必要があります。こうして、私がやりたいことはもっと理にかなっています。 – sebas