この質問は、モデルパーツなしでMVCを使用しようとしているように聞こえます。誤解している場合は、質問を編集して実際のユースケース(例)を含めると、コンテキストを理解するのに役立つ場合があります。
ただし、一般的には、コントローラーに実際に永続化/保存されるものはありません。したがって、「更新」または「通知」を必要とするコントローラーには何も存在しないはずです(つまり、データがありません)。むしろ、データはすべてのデータを管理する別の「モデル」レイヤーにある必要があります。次に、ビューがモデルレイヤーから読み取られ、そのビューのデータが取得されます。
簡単な復習については、 MVCのウィキペディアページをチェックしてください。このページには、優れた古典的なMVCフローチャートとコンポーネントの相互作用に関する簡単な説明があります。
議論の例
この問題を理解するために、例を考えてみましょう。
アプリケーションにユーザーのリストがあるとしましょう。このリストは次の場所に表示される場合があります。
- マスター管理者リストビュー
- 管理者編集ユーザービュー
- ユーザーの個人プロフィールビュー
- おそらくもっとある?
これらの各ビューは、モデルレイヤーからのデータを要求し、画面に何かを表示します。
ここで、1人のユーザーのプロファイルに変更がコミットされたとしましょう。これは、モデルにいくつかの変更を適用するために必要な作業を行うコントローラーメソッドを介して実行されます。
私の理解では、これらのすべてのビューを更新して、その変更を反映する必要があります。つまり、ビューはモデルからデータをリロードする必要があります。コントローラーがこのリロード/リフレッシュをトリガーしたとしても、コントローラー自体からこのデータを取得するべきではありません。むしろ、コントローラーメソッドがモデルレイヤーからのクエリを容易にする場合があります。重要な部分は、アプリケーション全体で複数のコントローラーにデータの複数のコピーを保持していないことです。永続性はモデルレイヤーに集中化されます。
WinFormsの場合、UIコンポーネントがそのインターフェイスを認識し、それに応じて更新するように構築されている場合、モデルレイヤーは前述のINotifyPropertyChangedインターフェイスのようなものを提供できる可能性があります。しかし、それはかなりプラットフォームに依存するアプローチです。
よりプラットフォーム/コンテキストにとらわれないアプローチは、すでに述べたpub-sub(publish-subscribe)パターンです。この場合、モデルに変更を加える各コントローラーメソッドは、その変更の通知も公開します。そのデータのすべてのビューは、モデルレイヤーからビューのデータを更新/再ロードすることにより、そのような通知をリッスンして応答できます。