コントローラーはビューとモデルについて知っている必要がありますか？またはその逆？

私はこれを行う必要があるかどうかを概念的に理解しようとしています：

item = Model()
screen = View()
brain = Controller(item, screen)

またはこれ..

brain = Controller()
item = Model(brain)
screen = View(brain)

またはこれ..

class Controller():
    def __init__(self):
        item = Model(self)
        screen = View(self)

または完全に何か他のもの？

私にとって、最初のオプションは理にかなっています。コントローラーの仕事は、ビューとモデルの間を調整することです。その観点から、コントローラーがビューとモデルへの参照を制御するものであることが理にかなっています。

モデルとビューのないコントローラーを実際に使用することはできませんが、ビューを持っているか、モデルを持っているだけのほうが理にかなっています（たとえば、単体テストの場合）。そのため、これらの依存関係を他の2つではなくコントローラーに渡します。

ModelそしてView互いに独立しています。

考えてはいけないControllerと脳 MVC構造の。考えてディスパッチャブラウザからの要求を処理し、ディスパッチにそれらをModel。次に、からデータを取得Modelし、テンプレートに適した方法でパッケージ化し、に送信しますView。

これModelはMVC構造の頭脳であり、これがビジネスルールを置くべき場所です。ビジネスルールは複数のコントローラーに共通です。そのため、ドキュメントコントローラーとレポートコントローラーの両方が、ユーザーモデルを使用して、これらのものにアクセスできるユーザーを確認できます。両方のコントローラーでこれらのルールを繰り返したくないでしょう。

View非データソースの特定の方法でデータを提示するHTMLテンプレートを使用する必要があります。データベースのスキーマに緊密にバインドしないでください。文書のタイトルを表示するには、ビューの出力に呼ばれるテンプレート変数の内容を持っているでしょうdocument_title、とだけControllerその変数が設定された方法を知っている、とだけModelそのドキュメントはそのタイトルを持っている理由を知っています。

MVCは元々、デスクトップアプリケーションのプログラミングを容易にするために定義されました。ビューはモデルイベントにサブスクライブし、モデルが変更されたときにプレゼンテーションを更新します。コントローラーは、ユーザーインターフェイスイベント（ボタンを押すなど）をモデルの呼び出しに変換するだけです。そのため、コントローラーとビューはモデルに依存していましたが、互いに独立していました。モデルは両方から独立していました。これにより、複数のビューとコントローラーが同じモデルで動作することができました。

Web 1.0アプリケーションに使用される「MVC」アーキテクチャ（ページ全体の更新、AJAXなし）は多少異なります。Web要求がコントローラーにディスパッチされます。コントローラーは何らかの方法でモデルの状態を変更し、ビューによってレンダリングされる1つ以上のモデルを送信します。コントローラーとビューは両方ともモデルに依存しますが、コントローラーもビューに依存します。

Web 2.0アプリケーションでは、クライアント側で従来のMVCアーキテクチャに戻ります。モデル、ビュー、コントローラーはすべてJavascriptオブジェクトとしてクライアント側に存在します。コントローラーは、ユーザーイベントをモデルアクションに変換します。モデルアクションによって、サーバーへのAJAX要求が発生する場合と発生しない場合があります。繰り返しますが、ビューはモデルイベントにサブスクライブし、それに応じてプレゼンテーションを更新します。

ビューは、モデルの変更をサブスクライブする必要があります。サブスクリプションは詳細（この特定のアイテムのインベントリの変更を表示）または汎用（モデルが変更された）であるため、サブスクリプションの豊富さには自由度があります。ビューは、変更通知に応じてモデルを照会する場合があります。ビューは、画面にモデル要素の目的のセットを表示し、変更通知を処理するときに画面を更新します。

コントローラは、ユーザーの指示の結果として、モデルに変更をプッシュする必要があります（キーボード入力、マウス、メニューコマンドなど）。

モデルは、モデルとサブスクリプションのリストを維持し、サブスクリプションを介してビューに適用可能な変更を通知する必要があります。

また、新しいビューとコントローラーを作成するメカニズムも必要です（MVCでは、同じモデルの2つ以上のビューを持つことができるはずです（同じビュー（ポイント）または異なるビュー（ポイント）である可能性があります）。論理的には、コントローラーは、ビューまたはコントローラー（ペア）ファクトリーを実行する必要があるか、コントローラーまたは別のコンポーネントの一部である可能性があると考えることができます。

MVCは、よりモジュール性のパターンに似ています。その目的は、ユーザーインターフェイスレイアウト（ビュー）を変更するたびに、アプリケーションロジック（コントローラー）または内部データ処理（モデル）を変更する必要がないことです。

これを実現するためのパターンは、各MVCコンポーネントの実装ロジックを分離することです。それでも、コンポーネントがお互いのインターフェースを知っていることは完全に正常です。

私がよく見たのは、コントローラーがモデルとビューを作成または呼び出し（インターフェイスを知っている）、モデルまたはビューがコントローラーに通知を返すことができることです（コールバックやオブザーバーパターンのように）。重要な部分は、コントローラーがレイアウト構造を認識していないことです。