MVCでは、複数のビューで同じコントローラーを使用できますか、または1つのビューで1つの一意のコントローラーを使用する必要がありますか？

MVCを中心としたプロジェクトのアーキテクチャを設計しているときに質問があります。（これはC ++ / Marmalade SDKプロジェクトです。特定のMVCフレームワークは使用していません。作成しています。）

いくつかの記事（元のSteve Burbek記事など）で、「MVCトライアド」という概念を読み続けています。初めて読んだとき、アプリケーションは「MVCトライアド」ユニット（想定している各UIピースに1つ）を中心に構築されているように見えましたが、これはかなり柔軟性に欠け、MVCの使用が意図されていなかったと思います。次に、この問題をさらに調査すると、コントローラーとビューの密結合の例、つまり1対1の関係が見つかりました-TextEditViewにはTextEditControllerがあります。

しかし、プロジェクトに戻ると、（AddElementControllerのような「論理ユニット」による）1つのコントローラーと、その特定のコントローラーの複数のビューがあると便利です。

私は、何らかのタブUIが必要なAddElementControllerのようなものについて明確に考えています。AddElementTabViewとタブ用の複数のAddImageView、AddSoundViewなどを持つAddElementControllerが必要ですか？または、タブビューごとに異なる「サブコントローラー」が必要ですか？

要約すると、MVCパターン（このフレームワークのXフレームワーク固有の理解/実装ではありません）に関して、コントローラーに複数のビューがあるのは正しいですか、または各ビューに特定のコントローラーが必要ですか？

また、いくつかの状態情報をコントローラーに保持するのは正しいですか、それともステートレスである必要があります（つまり、状態を非ドメイン状態モデルに配置する必要があるということですか）。

事前にすべてに感謝します。

問題は、MVCパターンが実際にはもう存在しないシステムで設計されていることです。UIライブラリが存在しなかったときにSmalltalkで発明されました。ウィンドウダイアログを作成するには、すべてのボックスを描画し、適切な正方形を強調表示し、描画していたテキストが正しい場所にあることを確認します...など...

1つの大きなキャンバスだけを使用してダイアログアプリを作成することを想像してください。それがMVCの由来する世界です。

このシステムの「ビュー」はテキストボックスであり、ボックス、テキストの描画、選択領域の描画、テキストの変更への応答などを担当するクラスでした。

「コントローラー」は、このボックス内で発生したマウスイベント、キーダウン、キーアップ、クリックなどのマウスイベントを取得する別のクラスで、何が起こったかを決定します。テキストを変更する必要がありますか？選択を変更する必要がありますか？そのようなもの。

「モデル」は、コンポーネントの基本データと状態を表すさらに別のクラスです。テキストボックスモデルには、もちろんテキスト、フォント、選択などが含まれます。

ご覧のとおり、このような状況では、3つのコンポーネントが1つのアイデアの表現に非常に絡み合っています。この文脈では、「トライアド」と言っても理にかなっています。

現在、UIライブラリの作成と生の描画コマンドの使用に取り組んでいる場合、同様のことを行うことができます。しかし、「MVC」パターンの適用は当初の目的を超えて広がっています。現在では、実際には完全なダイアログである「ビュー」と、「textChanged」や「buttonClicked」などのイベントに応答するコントローラーがあります。今日のMVCのモデルは通常、システムからかなり切り離されたものであり（ただし、通常、ある種のオブザーバーインターフェイスを提供することでビューにリンクされています）、1つのモデルに関連するビューが多数存在する場合があります。

たとえば、最近設計したシステムでは、10個以上のビューがあり、すべてが単一のドキュメント「ホルダー」とそのアクティブドキュメントを監視していました。メインの描画インターフェイスは、ドキュメントのレイアウト、選択されたアイテムを監視してレコードインターフェイスを提供するさまざまなプロパティビュー、および表示されるウィンドウだけではなくドキュメント全体を表示するメインビューの縮尺表現と対話しました。これらのビューの一部には、GUIイベントをドキュメントの変更に変え、さまざまなビューに通知するさまざまな複雑さのコントローラーがありました。

あなたはまだそのような関係を「トライアド」と呼ぶことができますか？おそらく、しかし、MVCの以前の古いアプリケーションの多くを暗示していると思います。

異なるビューでコントローラーを共有できますか？ビューの類似度に依存します。一般的に言って、このタイプのオブジェクトは、それが制御しているビューと、非常に再利用可能なように操作しているモデルに固有の動作を持っていることがわかりました...しかし、常に例外があります。

場合によります。MVCにはいくつかのバリアントがあり、1対1の関係だけが意味をなすもの（「謙虚なダイアログボックス」など）とそうでないものがあります。最も重要なMVCバリアントについて説明する「Build Your Own CAB」シリーズの記事を読むことをお勧めします。

ビューには、MVCにコントローラーはありません。コントローラーはボスなので、コントローラーはどのビューをレンダリングするかを決定し、ビューはどのコントローラーがビューを要求したかを気にしません。

コントローラーから複数のビューを絶対に持つことができます。MVCパターンに固執したい場合は、ビューごとにモデルを作成することを検討してください。

コントローラーのポイントは、ドメインモデルとのユーザーの対話を制御することです。つまり、ユーザーが見るもの（ビュー）とアプリケーションの状態（モデル）の間の間接的なレベルです。

ユーザーがリクエストを行うと、コントローラーに送信されます。コントローラーは、通常何らかのサービスクラスを介して、その要求をアプリケーションに中継する方法を決定します。次に、そのサービスクラスからの応答を解釈し、ユーザーに送り返すビューを決定します。

ユーザーがコントローラーに対して行うことができる要求が1種類しかない場合、コントローラーは常に同じビュー（1：1）を返すことがあり、常に同じ種類の応答が必要です。たとえば、HelloWorldControllerは常にHelloWorldView「Hello、World！」を表示します。

一方、コントローラーは、モデルが何を伝えるかに応じて、多くの場合、異なるビューを決定する必要があります。TeamRosterController返される可能性がありますRugbyTeamRosterViewまたはFootbalTeamRosterView要求されたチームの種類に応じて、。

一般に、コントローラーはステートレスであることが望ましいですが、ユーザーセッションの状態へのアクセスが必要または望ましい場合もあります。可能であれば、その状態へのアクセスを個別に管理する必要があります。

実際のMVCフレームワークを見て、その機能と動作を確認することを強くお勧めします。使用する必要はありませんが、独自に構築する前に、確実に理解を深めることができます。