MVCでは、モデルにサブビューモデルを含める必要がありますか？
いくつかの背景：
同僚と私はMVCの解釈が異なります。つまり、同じ問題を考えれば、根本的に異なる解決策を考え出していることになります。彼はJavaバックグラウンドから来ており、MVCのすべてのコンポーネントが伝統的にオブジェクトをモデル化している可能性があり、私はHaskellバックグラウンドから来ており、OOPの経験がほとんどまたはまったくありません。
問題スペース：
モデル化しようとしている問題は、デスクトップ環境に少し似ています。ユーザーセッション（おそらくユーザーのログイン、デスクトップの背景）とデスクトップ上のプロセス（iTunes、Finderなど）には、それぞれ独自のモデルプロパティ（最小化など）があるという概念があります。
次の点については同意します。HMVCが最高の表現であると考えています。 Session（デスクトップ）とProcess（アプリケーション）という2つのMVCオブジェクトがあり、ProcessにSessionまたはバックリンク。
ただし、MVCの中心的な意味と、ユーザーのデスクトップ上のプロセスのリストを保持する場所にどのように影響するかについては、意見の相違があります。
彼の解釈：
彼は伝統的にコードやレンダリングシステムで簡単にモデル化できる非常に有効なポイントを主張しています。彼は、プロセスのリストはProcessController内のSessionControllerオブジェクトのリストである必要があり、モデルはそれらの内部に個別のオブジェクトとして存在していると述べています。これは、SessionControllerとSessionModelの両方にかなりの量の状態があり、SessionViewがレンダリングする必要があるものに関連していることを意味します。
これは、簡単な検索でインターネット上で読み取ることができたものと非常に調和しているようです。
私の解釈：
私の解釈では、最大のアーキテクチャ変更が必要であり、コードでの実装は難しいようですが、概念的には正しいと思います。なぜこれが当てはまらないのか、またはこの解釈に沿った別のモデル（MVCでない場合）を提示し、両方のパターンの長所と短所を強調して、最も情報に基づいた決定を下せるように誰かに説明してほしい（どちらも持っていない）ソフトウェアアーキテクチャの強力な背景）。
私はMVCを、Model、Controller、およびViewの3つの交換可能なコンポーネントを持つトライアドとして見ています。これは、私がインターネット上で読むことができるものと一致し、一部のソースは、「ビュー、コントローラー、および同じインターフェースを持つモデルは、異なる効果に交換可能である必要がある」のようなものに沿って物事を言うでしょう。これが機能すると想像する方法は次のとおりです。
- モデルを交換すると、データが検証または保存される方法が変更されます
- コントローラーを交換すると、ページの動作が変更されますが、cを変更する可能性のあるものは変更されませんページのデータ内容
- ビューを交換すると、ページの表示方法が変更されます表示されます
このことから、ModelとViewが与えられた場合、コントローラーは動作を変更するだけでコンテンツの内容は変更しないため、コントローラーだけをスワップしてもページが最初に表示するデータは変更されないはずだと考えましたページ。これは、コントローラを鉄道システムの「駅コントローラ」として概念的に視覚化したもの、モデルとしての鉄道の計画、および実際の物理的な外観とトラックの外観/感触（さまざまなフレーバーで、「ビューとして「リアル」または「バーチャル3D」）。
ここで私たちは同意しません：
SessionViewでユーザーに表示されるデータは、デスクトップ上のさまざまなプロセスによって変更されるためです（私はプロセスを関連データとしてモデル化しています）、SessionModelにはProcessModelのインスタンスのリストが含まれている必要があります。つまり、同じSessionControllerで任意のSessionViewを使用すると、概念的には同じデータ（デスクトップ上のプロセス）が表示されます。
彼は、Modelが別のモデルについて決して知らない方が理にかなっていると主張します。つまり、SessionControllerにはProcessControllersのリストがあり、各Controllerオブジェクトにはそのモデルへのリンクがあります。 SessionViewと同じSessionModelであるがSessionControllerが異なる場合、ユーザーに表示されるデータは根本的に異なるはずです。
それぞれの解釈について議論し、最も十分な情報に基づいた結果に到達するために私たちを助けてください。
御時間ありがとうございます！
MVCは単純に [〜＃〜] srp [〜＃〜] UIコードに適用されるため、MVCを理解する上での鍵は責任の分離にあります。表示する必要のあるデータ、その表示方法、画面イベントの処理方法を分離します。しかし、MVCの元の定義の重要な（そしてしばしば見落とされている）詳細は、MVCがはるかに細かいレベルで設計されていることです。たとえば、ButtonModel、ButtonView、ButtonControllerの各オブジェクトがあり、画面上に1つのボタンを表示するだけです。この詳細が欠けていると、このテーマに関して非常に多くの異なる意見が出されます。 Java Swingアーキテクチャ をチェックして、私の意味を確認できます。
MVCのポイントは、各責任を果たすコードを、他のコードに影響を与えることなく変更できるようにすることです。たとえば、データ表現やイベント処理ロジックに触れる必要なく、画面（のコンポーネント）のレンダリングを切り替えることができます。したがって、ある程度、これはあなたがここで言うことと一致します。
このことから、コントローラーはページの「コンテンツ」ではなく動作のみを変更する必要があるため、モデルとビューがあれば、コントローラーのみをスワップしてもページが最初にレンダリングするデータは変更されないはずだと考えました。これは、コントローラを鉄道システムの「駅コントローラ」として概念的に視覚化したもの、モデルとしての鉄道の計画、および実際の物理的な外観とトラックの外観/感触（さまざまなフレーバーで、「ビューとして「リアル」または「バーチャル3D」）。
ただし、コンテキストでは、細分性のレベルはオフです。画面全体を担当しているように見えるSessionViewがあります。このレベルでは、MVCが意図したとおりに責任が完全に分離するには結合しすぎてしまうため、十分なメリットが得られない可能性があります。
問題は、セッションとプロセスの両方で3つのUIの役割（レンダリング、データ、およびイベント処理）を分離することであり、合計6つです。コンポーネント（画面全体）の細かさのレベルのため、これは不可能になり、思いがけない不協和音を引き起こします。
セッションとプロセスの両方のレンダリングとイベント処理の責任を分離したいのですが、それらのデータを結合します。同僚はデータを分離したいが、イベント処理を結合したいと考えています。
結局、これはSRPの問題です。私の解決策は、セッションをプロセスから明確に分離できるレベルまで粒度レベルを下げることです。経済学のためにそれを行うことができない場合は、トレードオフの両側に重みを付け、最悪のものを選択し、技術的負債としてサインオフする必要があります。結局のところ、これがすべての設計上の決定です。 :)