私は最近、PHP フレームワークを?qū)Wぼうと計畫しましたが、MVC についての以前の理解が非常に表面的であることがわかりました。しかし、Laravel のドキュメントを見ると、MVC についてまだ混亂しています
たとえば、Todo リストを作成する場合は、フロントエンド MVC に従って次のように作成します。
一般に、このような関係があります (あまり正確ではなく、さまざまな MVC 実裝は完全に一貫性がありません):
全體としてはサイクルです~モデルから始まり、途中でユーザー操作を追加し、その後モデルに戻ります
これはグラフィックスを書くためのアイデアであり、データをインターフェイスから分離し、プログラムを簡素化することです。
つまり、インターフェースを表す最小限のデータをModelとして抽象化し、最小限の操作をControllerとして抽象化します
ビューはモデルに応じて変化し、ユーザーのニーズに応じて自由に変更することもできます。
おおよそ:
または:
以下の回答は個人的な意見ですので、間違っていたらご指摘ください。
まずネイティブ PHP について話しましょう。
データ処理では、ページが互いにネストされて一緒に表示されます。
MVC は異なり、データ処理と表示が分離されています。
業(yè)務が複雑でなければ、基本的にVとCで対応できます。
兄 C はデータを処理してパッケージ化し、V に渡しました。 V に厳粛に伝えてください:「V 兄弟、データはすべてここにあります。受け取って表示してください!」
V は「わかりました、C 兄さん!」と言って、フロントエンドにデータを表示しました。 Brother V には、Brother C から與えられたデータを表示するために使用される foreach に似た構(gòu)文もあります。
時々業(yè)務が複雑になり、C 兄は一人でデータを処理するのに少し疲れたので、C 兄は M 兄に手伝ってもらうよう電話します。
兄弟 M は、兄弟 C が反復作業(yè)を行うのを手伝い、それを処理した後、それを兄弟 C に渡します。その後、C 兄弟はそれを V 兄弟に渡します。
ネイティブ PHP はアウトソーシングのようなもので、多くの場合、1 人がフロントエンドとバックエンドを処理しなければなりません。
MVC は、フロントエンドとバックエンドを備えた成熟した企業(yè)のようなものです。役割分擔が明確です。
実際、MVC の意味は微妙に変化しています。CS ソフトウェアの本來の MVC と、今日の php Ruby Python の MVC には大きな違いがあります。この概念がずっと前に MVP になっている可能性さえありますが、誰もが MVC に慣れていて、それを誤解しています
実際のプロジェクトで考えると、3つの思考実験をすることでMVCの本質(zhì)や目的が大體理解できると思いますが、具體的に3層にするか、4層にするか、2層にするかは実際にどうやって実現(xiàn)するかです。柔軟性と保守性、それは単なる性的手段です
データベースを mysql から pgsql、さらには mongodb に移行する場合、プロジェクトにはどの程度の変更が必要ですか?
理想的な MVC アーキテクチャでは、ビジネス コード (モデルを含む) を変更する必要がなく、構(gòu)成ファイルを変更するだけで済み、多くても新しい DBAL ドライバーを作成するだけで済みます
実際の狀況では、DB ごとに機能に微妙な違いがあるため、モデルを微調(diào)整することで解決する必要があります。
あなたの答えが見て見ぬふりなら、それは再度書き直すのとほぼ同じです。その場合、M 層は十分に獨立していないので、モデルに書かれたコードを他の場所に分散する時期が來ています
すべての機能が変更されていない(すべての機能が合理的で自然なモバイル バージョンのインタラクションを備えている)と仮定して、サイトにモバイル バージョンを追加すると、プロジェクトにはどの程度の変更が必要になりますか?
答えは、一連のビューを書き換えてから、コントローラーを 1 行に変更することですif(isMobile) use(MobileView);
コントローラーで多くのロジックを変更する必要があり、モデルも関係していることがわかった場合、V レイヤーは十分に獨立していません
すべての機能が変更されていないと仮定すると、(サードパーティまたはモバイル アプリケーションで使用するために) オープン API をサイトに追加すると、プロジェクトにはどの程度の変更が必要になりますか?
答えは、新しい承認、データ形式、検証ロジックを含むコントローラーの新しいセットと、単純なビュー (json または xml のみを出力する) であるはずです
モデルを変更する必要がある、元のビューの一部を移動する必要がある、または古いコントローラーに元々書かれていたコードの一部をコピーする必要があることが判明した場合は、C レイヤーが十分に獨立していないことになります
最も鮮明で簡単なことは、MVC を私たちが子供の頃に遊んだカードベースのゲーム コンソールと比較することです:
M: ゲームカード、データの保存、ビジネスロジックなどを擔當します
V: ゲーム畫面を表示するのはテレビです
C: これはゲーム コントロール ハンドルであり、最初の 2 つの相互作用を擔當します
ショッピングウェブサイトを例に挙げてみましょう。
たとえば、Web サイトのユーザー データには、各ユーザーが複數(shù)の注文を行うことができ、各注文には注文番號、価格などが含まれます。
V は、製品リストの表示や個人の注文履歴の表示など、表示される HTML インターフェイスがどのようなものであるかというビューを提供します。
C はコントローラーであり、M からデータを抽出して V に表示する責任があります。たとえば、過去 1 週間の個人の注文履歴を確認したい場合、V は M からのすべての注文を検索し、1 週間前の注文データをフィルタリングして除外し、殘りを表示するために V に提供する責任があります。
MVC を理解するための前提條件はコード階層化の概念であり、コード階層化の目的は分離です。
2 つの質(zhì)問に答えてみてください:
ソフトウェアは、ユーザーがビュー上でビジネス要件をトリガーするところから始まり、プログラムが特定のビジネス ロジックに従って要件を処理し、処理結(jié)果がビュー上でユーザーにフィードバックされるまでのプロセス全體のコードは次のとおりです。ビュー操作、ビジネス ロジック処理、ビューとビジネス ロジック間の接続という 3 つの主なタスクを擔當します。
コードがプログラム內(nèi)で階層化されていない場合、これら 3 つの側(cè)面の実裝は 1 つのクラスに結(jié)合されます。コードの保守性、可読性、柔軟性を高めるために (@mcfog の回答を參照してください)、これらのコードは側(cè)面に応じて異なるクラスに記述し、同じ側(cè)面を持つクラスをパッケージに含める必要があります。まるで違うレベルにいるかのように。
mvc は、成熟した階層化 (分離) ソリューションです。
最初の質(zhì)問に対する答えによると、異なるレベルのコードを異なるクラス (およびパッケージ) に配置する必要があるため、これらの異なるレベルのコードはどのように連攜するのでしょうか?
この質(zhì)問に対する他の回答は、この質(zhì)問に寫真とテキストを使って具體的に回答しているようです。
モデル內(nèi)のコードはビジネス ロジックを擔當します。
ビュー內(nèi)のコードはユーザー操作を擔當します
コントローラー內(nèi)のコードは、モデルとビュー間の接続を擔當します。
モデルビューコントローラーのモデル、ビュー、コントローラー
モデル: データモデル
ビュー: UI 関連要素
コントローラー: モデルとビューを接続するために使用されます
シンプルであればあるほど良いですよね?
M: モデル - データをどのようにモデル化するか、またはデータを表すためにどのような構(gòu)造が使用されているか
C: コントローラー - ビジネス ロジックをどのように処理するか。この「処理」は主に 2 つの端に対応します。一方の端は、処理に必要なデータ ソースをモデルから要求することであり、もう一方の端は、処理結(jié)果をビューに渡すことです。途中の特定のプロセスはコントローラーが擔當するレベルです
V: ビュー - ビジネス処理の結(jié)果をクライアントにどのように提示し、対話を提供するか
実際、あまり簡単に言うのは良くありません。それを裏付ける十分な知識と経験がなければ、一部の詳細は簡単にするために高度に要約および抽象化することしかできないため、それは霧の中で花を見るようなものです。
上記のみんなの回答を読んで、私は最終的に次のことに気づきました。V はユーザーが見るためのもので、C はユーザーが制御するもので、M はユーザーがアクセスできないものです。C と V を介して M を制御できますか?
SO での MVC についてのディスカッション: MVC とは実際何ですか?
簡単に言うと、データベース(モデル)とデータ表示(ビュー)のコードを混同しないでください。追加する必要があるビジネスロジックがある場合、それはコントローラー(コントローラー)です。