c ++モデルビュープレゼンター：プレゼンターを構築する場所は？

MFCプロジェクトでThe Humble Dialog Boxペーパー（pdf）に記載されているモデルビュープレゼンター（MVP）パターンを使用しています。問題はほとんどのGUIツールキットと同じだと思います。

私を悩ませているのは、プレゼンターだけでなく、プレゼンターが必要とするサービスも作成している具体的なビュー（つまり、ダイアログクラス）です。それは正常ですか？ビューがプレゼンターが必要とするサービスを知る必要があるのはなぜですか？私が考えているのは、プレゼンターをダイアログクラスに依存的に挿入する必要があるということです。

アプリケーションのメインコントロールは、CWinAppから派生したクラスです。では、このクラスでサービスとプレゼンターを作成してから、ダイアログクラスに挿入する必要がありますか？

ただし、プレゼンターがコンストラクターでビュークラスへの参照を必要とする場合、ダイアログクラスにプレゼンターを依存性注入するにはどうすればよいですか？

MyPresenter(IView *view, MyService *service);

また、メインウィンドウがポップアップウィンドウからスポーンした場合、そのウィンドウプレゼンターとサービスの詳細はどこに構築する必要がありますか？

これはC ++なので、どんな種類のDIフレームワークにも興味があるとは思いません。

更新

私が持っていた1つのアイデアは、nullビューでプレゼンターを作成し、コンストラクターがプレゼンターをダイアログクラスに挿入し、ダイアログクラスのコンストラクターでSetView(IView *view)プレゼンターのメソッドを呼び出すthis場所thisがダイアログクラスになる場所（IViewから派生）でした。 ）。そう：

MyApp::Start()
{
  SomeService *service = new SomeService();
  MyPresenter *presenter = new MyPresenter(null, service);
  MyDialog *dialog = new MyDialog(presenter);
  ...
}

MyDialog::MyDialog(MyPresenter *presenter):
 presenter_(presenter)
{
  presenter_->SetView(this);
}

少しぎこちないように見えますが、サービスの構築をDialogクラスから除外しています。空のビューは少し危険なようです。代わりの方法は、空のメソッド本体を持つNullViewクラスを実際に作成し、それをプレゼンターコンストラクターに渡すことです。

おそらく、より良い解決策は、プレゼンターを構築する方法を知っているファクトリクラスまたはメソッドを使用することですか？ビューはそれ自体をファクトリーメソッドに渡し、戻り値をプレゼンターメンバーに格納します。

これにより、プレゼンターの構成方法（サービスなどへの依存性）に関する情報がビュー自体から切り離されます。

あなたの元のアイデア（プレゼンターとサービスをビューの中に構築する）は害を及ぼさないと思います。注射のメリットを自問する必要があり、私は何も見ていません。

実際のビューを抽象的なビューとプレゼンターに分離することにより、関心の分離をすでに達成しました。そして、たとえば、詰め込みビューまたは模擬ビューでプレゼンターをテストすることにより、この成果から利益を得ることができます。では、なぜプレゼンターを具体的な視野に入れたいのですか？必要はないと思います。