たとえば、Todo リストを作成する場合は、フロントエンド MVC に従って次のように作成します。

• モデル: データベース内のコンテンツ (テキスト、完了ステータス) に対応する JSON 配列
• ビュー: インターフェイスである HTML テンプレート、または DOM テンプレート
• コントローラー: ユーザーはインターフェースを操作し、モデルを変更します

一般に、このような関係があります (あまり正確ではなく、さまざまな MVC 実装は完全に一貫性がありません):

• モデルの変更に合わせてプログラム全体が更新されます
• ビューはモデルに従ってレンダリングされ、モデルが更新されると更新されます
• コントローラーはビューでイベントトリガーを受け取り、モデルを変更します

全体としてはサイクルです~モデルから始まり、途中でユーザー操作を追加し、その後モデルに戻ります
これはグラフィックスを書くためのアイデアであり、データをインターフェイスから分離し、プログラムを簡素化することです。
つまり、インターフェースを表す最小限のデータをModelとして抽象化し、最小限の操作をControllerとして抽象化します
ビューはモデルに応じて変化し、ユーザーのニーズに応じて自由に変更することもできます。

おおよそ:

または:

以下の回答は個人的な意見ですので、間違っていたらご指摘ください。

まずネイティブ PHP について話しましょう。
データ処理では、ページが互いにネストされて一緒に表示されます。

MVC は異なり、データ処理と表示が分離されています。
業務が複雑でなければ、基本的にVとCで対応できます。
兄 C はデータを処理してパッケージ化し、V に渡しました。 V に厳粛に伝えてください:「V 兄弟、データはすべてここにあります。受け取って表示してください!」
V は「わかりました、C 兄さん!」と言って、フロントエンドにデータを表示しました。 Brother V には、Brother C から与えられたデータを表示するために使用される foreach に似た構文もあります。

時々業務が複雑になり、C 兄は一人でデータを処理するのに少し疲れたので、C 兄は M 兄に手伝ってもらうよう電話します。
兄弟 M は、兄弟 C が反復作業を行うのを手伝い、それを処理した後、それを兄弟 C に渡します。その後、C 兄弟はそれを V 兄弟に渡します。

ネイティブ PHP はアウトソーシングのようなもので、多くの場合、1 人がフロントエンドとバックエンドを処理しなければなりません。
MVC は、フロントエンドとバックエンドを備えた成熟した企業のようなものです。役割分担が明確です。

実際、MVC の意味は微妙に変化しています。CS ソフトウェアの本来の MVC と、今日の php Ruby Python の MVC には大きな違いがあります。この概念がずっと前に MVP になっている可能性さえありますが、誰もが MVC に慣れていて、それを誤解しています

実際のプロジェクトで考えると、3つの思考実験をすることでMVCの本質や目的が大体理解できると思いますが、具体的に3層にするか、4層にするか、2層にするかは実際にどうやって実現するかです。柔軟性と保守性、それは単なる性的手段です

データベースの選択を変更する

データベースを mysql から pgsql、さらには mongodb に移行する場合、プロジェクトにはどの程度の変更が必要ですか?
理想的な MVC アーキテクチャでは、ビジネス コード (モデルを含む) を変更する必要がなく、構成ファイルを変更するだけで済み、多くても新しい DBAL ドライバーを作成するだけで済みます
実際の状況では、DB ごとに機能に微妙な違いがあるため、モデルを微調整することで解決する必要があります。

あなたの答えが見て見ぬふりなら、それは再度書き直すのとほぼ同じです。その場合、M 層は十分に独立していないので、モデルに書かれたコードを他の場所に分散する時期が来ています

モバイルHTML5バージョン

すべての機能が変更されていない（すべての機能が合理的で自然なモバイル バージョンのインタラクションを備えている）と仮定して、サイトにモバイル バージョンを追加すると、プロジェクトにはどの程度の変更が必要になりますか?
答えは、一連のビューを書き換えてから、コントローラーを 1 行に変更することですif(isMobile) use(MobileView);

コントローラーで多くのロジックを変更する必要があり、モデルも関係していることがわかった場合、V レイヤーは十分に独立していません

APIを追加しました

すべての機能が変更されていないと仮定すると、(サードパーティまたはモバイル アプリケーションで使用するために) オープン API をサイトに追加すると、プロジェクトにはどの程度の変更が必要になりますか?
答えは、新しい承認、データ形式、検証ロジックを含むコントローラーの新しいセットと、単純なビュー (json または xml のみを出力する) であるはずです

モデルを変更する必要がある、元のビューの一部を移動する必要がある、または古いコントローラーに元々書かれていたコードの一部をコピーする必要があることが判明した場合は、C レイヤーが十分に独立していないことになります

最も鮮明で簡単なことは、MVC を私たちが子供の頃に遊んだカードベースのゲーム コンソールと比較することです:
M: ゲームカード、データの保存、ビジネスロジックなどを担当します
V: ゲーム画面を表示するのはテレビです
C: これはゲーム コントロール ハンドルであり、最初の 2 つの相互作用を担当します

ショッピングウェブサイトを例に挙げてみましょう。
たとえば、Web サイトのユーザー データには、各ユーザーが複数の注文を行うことができ、各注文には注文番号、価格などが含まれます。
V は、製品リストの表示や個人の注文履歴の表示など、表示される HTML インターフェイスがどのようなものであるかというビューを提供します。
C はコントローラーであり、M からデータを抽出して V に表示する責任があります。たとえば、過去 1 週間の個人の注文履歴を確認したい場合、V は M からのすべての注文を検索し、1 週間前の注文データをフィルタリングして除外し、残りを表示するために V に提供する責任があります。

MVC を理解するための前提条件はコード階層化の概念であり、コード階層化の目的は分離です。

2 つの質問に答えてみてください:

1. なぜコードを分離する必要があるのですか?
2. どのように切り離すか?

コードを分離する必要がある理由

ソフトウェアは、ユーザーがビュー上でビジネス要件をトリガーするところから始まり、プログラムが特定のビジネス ロジックに従って要件を処理し、処理結果がビュー上でユーザーにフィードバックされるまでのプロセス全体のコードは次のとおりです。ビュー操作、ビジネス ロジック処理、ビューとビジネス ロジック間の接続という 3 つの主なタスクを担当します。

コードがプログラム内で階層化されていない場合、これら 3 つの側面の実装は 1 つのクラスに結合されます。コードの保守性、可読性、柔軟性を高めるために (@mcfog の回答を参照してください)、これらのコードは側面に応じて異なるクラスに記述し、同じ側面を持つクラスをパッケージに含める必要があります。まるで違うレベルにいるかのように。

切り離す方法

mvc は、成熟した階層化 (分離) ソリューションです。

最初の質問に対する答えによると、異なるレベルのコードを異なるクラス (およびパッケージ) に配置する必要があるため、これらの異なるレベルのコードはどのように連携するのでしょうか?

この質問に対する他の回答は、この質問に写真とテキストを使って具体的に回答しているようです。

モデル内のコードはビジネス ロジックを担当します。 ビュー内のコードはユーザー操作を担当します
コントローラー内のコードは、モデルとビュー間の接続を担当します。

モデルビューコントローラーのモデル、ビュー、コントローラー
モデル: データモデル
ビュー: UI 関連要素
コントローラー: モデルとビューを接続するために使用されます

シンプルであればあるほど良いですよね？

M: モデル - データをどのようにモデル化するか、またはデータを表すためにどのような構造が使用されているか

C: コントローラー - ビジネス ロジックをどのように処理するか。この「処理」は主に 2 つの端に対応します。一方の端は、処理に必要なデータ ソースをモデルから要求することであり、もう一方の端は、処理結果をビューに渡すことです。途中の特定のプロセスはコントローラーが担当するレベルです

V: ビュー - ビジネス処理の結果をクライアントにどのように提示し、対話を提供するか

実際、あまり簡単に言うのは良くありません。それを裏付ける十分な知識と経験がなければ、一部の詳細は簡単にするために高度に要約および抽象化することしかできないため、それは霧の中で花を見るようなものです。

上記のみんなの回答を読んで、私は最終的に次のことに気づきました。V はユーザーが見るためのもので、C はユーザーが制御するもので、M はユーザーがアクセスできないものです。C と V を介して M を制御できますか?

SO での MVC についてのディスカッション: MVC とは実際何ですか?

簡単に言うと、データベース(モデル)とデータ表示(ビュー)のコードを混同しないでください。追加する必要があるビジネスロジックがある場合、それはコントローラー(コントローラー)です。