従来の MVC での情報の流れ。
MVC のデータは、モデルからコントローラーを介してビューに移動するべきではありません。それは本来のコンセプトに違反しています。
MVC 設計パターンの元の定義を読むと、ビューがモデルからデータを要求することを意図していることに気付くでしょう。また、ビューはモデルの変更を監視しているため、いつそれを行うべきかを知っています。
現代の解釈。
元の概念では、アプリケーション内の各要素に対して小さな MVC トライアドを用意することを意図していました。現代の解釈では ( Martin Fowlerによると)、モデルはもはや単一のオブジェクトまたはクラスではありません。モデルは、オブジェクトのいくつかのグループを含むレイヤーです。それぞれに異なる一連の責任があります。
また、Web の台頭に伴い、別の問題が発生しました。Web サイトに従来の MVC を使用することはできません。理論的には、ソケットを開いたままにし、モデル層で何かを変更するたびにブラウザーに通知をプッシュすることで、これを実現できます。
しかし実際には、100 人の同時ユーザーがいるサイトでも問題が発生し始めます。また、MVC を使用してブログを作成することはありません。小規模なソーシャル ネットワークでさえ、このようなアプローチを使用することは不可能です。
当初のコンセプトからの逸脱はそれだけではありませんでした。
MVC にインスパイアされたパターン
現在、古典的な MVC (もはやそれほど古典的ではありません) とともに。MVC にヒントを得た 3 つの主要なパターンがあります。
モデル2 MVC
これは基本的に従来の MVC パターンと同じですが、後でモデルとビューの間にオブザーバーの関係はありません。このパターンは、私にとってより Web 指向のものです。ユーザー リクエストを受け取るたびに、モデル レイヤーで何かが変更されることがわかります。したがって、各ユーザー要求により、ビュー インスタンスはモデル レイヤーからの情報を要求します。
MVP
このパターンでは、代わりにコントローラーをプレゼンターに置き換えます。プレゼンターはモデル レイヤーからデータを要求し、それを現在のビューに渡します。ここでパターンの定義を見つけることができます。実際にはもっと複雑で、正直なところ、私はそれを完全には理解していません。
この場合、ビューはパッシブであり、モデル レイヤーからのデータを要求しません。
MVVM
このパターンは、従来の MVC よりも MVP ヘンに近いです。この場合、コントローラーのような構造 (実際にはモノリス クラス以上のもの) がモデル レイヤーからデータを要求し、(パッシブ) ビューで期待されるようにデータを変更します。
このパターンは主に、開発者がビューやモデル レイヤーに対して完全なコントローラーを持っていない状況を対象としています。たとえば、モデル レイヤーが SAP であるアプリケーションを開発している場合です。または、既存のフロントエンド インフラストラクチャを使用する必要がある場合。
参考までに、ASP.NET MVC で「MVVM」と呼ばれるものは、実際には適切な Model2 実装です。「ビューモデル」と呼ばれるものは、実際にはビュー インスタンスであり、「ビュー」はビューで使用される単なるテンプレートです。