View が IView インターフェイスを実装する WinForm である MVP プロジェクトを作成しました。私はコードを見直し、できる限り改善している最中です。ビューとプレゼンターがどのように相互作用するかについて、あなたの考えをお聞きしたいと思います。あなたの意見では、次のうちどれがベストプラクティスですか?
たとえば、私の MVP は、シリアルポート経由で通信するサービスを使用しています。リモート デバイスに接続するために、ビューは public Presenter メソッド Connect() を呼び出し、それから適切なサービス メソッドを呼び出します。
Connect() イベントを発生させ、プレゼンターにそれをリッスンさせる方が良い方法でしょうか?
通常、ビューはプレゼンターに依存し、プレゼンターはモデルに依存するように作業します。これは、複数のプレゼンターが同じモデルを使用でき、同じプレゼンターを複数のビュー (異なる UI レイアウト、または Winforms と Web など) で使用できることを意味します。これを容易にするために、ビューはプレゼンターのパブリック メソッドを呼び出し、プレゼンターからのイベントをリッスンして、データがいつ変更されたかを伝えます。
この方法で作業する理由の例として、初心者ユーザー用とエキスパート用の 2 つのビューがあり、初心者用ビューにエキスパート コマンドのサブセットが表示されているインターフェイスを想像してみてください。これらのビューの両方に同じプレゼンターが使用されている場合、ビギナー ビューはすべてのエキスパート コマンドのイベントを公開する必要があります。これは、プレゼンターがそれらにバインドできるように、それらがトリガーされることはありませんが、そこにいる必要があるためです。一方、プレゼンターはすべてのエキスパート オプションのメソッドを公開でき、ビギナー ビューはそれらを呼び出すことはありません。これは、ビューもプレゼンターも未使用の機能を実装していないことを意味します。
ここで私が従うガイドラインは次のとおりです。「プレゼンターのパブリック メソッドはパラメーターなしである必要があります。ビュー オブジェクトは、プレゼンターのパラメーターなしのメソッドのみにアクセスする必要があります。別のオプションは、プレゼンターがサブスクライブできるイベントをビューで定義できることです。いずれにしても、パラメーターを渡す必要はありません。 ." . 提案やコメントを受け付けています。