MVCはPHPプログラミングのSEOにすぎませんか？

およそ何億もの「PHPフレームワーク」があります。そしてそれらのほとんどは、MVCパターンに従って自分自身に請求します。osCommerceのコーディングスタイル（SQLとHTMLと非常に混ざり合った処理ロジック）を克服することは歓迎されますが、保守可能なアプリケーション設計を実現するためのアプローチは確かに単純で簡単です。

元のMVCコンセプトは、GUIアプリケーションを対象としていました。そして、Gtk / Pythonの場合は、それに応じて実行するのが現実的であるように思われます。しかし、PHP Webアプリはライブビュー（GUI要素）と永続的なコントローラーランタイムでは動作しません。使用されているコード+ディレクトリのグループ化またはクラスの名前付けだけを記述しているのであれば、それは間違いなく間違いです。

「MVC」は、PHPフレームワークの流行語のように使用されているようです。そして、私は実際に1つまたは2つの成熟したPHPフレームワークがそれを認めているのを見ましたが、とにかくフレーズを再定義して内部に一致させます。
それは一般的にヘビ油ですか？なぜより良い用語が使われず、メンテナンス可能なPHPのためのより賢明な概念が広まったのですか？

いくつかの手の込んだ推論

PHPの実装が実際のMVCパターンに従っていないと思うのはなぜですか。

モデル：理論的には、モデルは太く、ビジネスロジックを含み、コントローラーはシンハンドラー（入力->出力）である必要があります。実際には、PHPフレームワークは浅いモデルを提唱しています。CIとSymfonyの例は、等価なモデル== ORMです。HTTP入力もコントローラーによって処理され、モデルとして扱われません。

ビュー：AJAXが割引された回避策。Webページにビューを含めることはできません。PHPフレームワークはまだページを送り出します。インターフェースは通常のHTTPモデルに準拠していますが、MVC以外のアプリケーションに勝る利点はありません。（そして最後に、広く普及しているphpフレームワークは、実際にはHTMLではなくGUIビューに出力できません。Gtk/ Console / Webを操作できるPHPライブラリを見たことがありますが、フレームワークはできません。）

コントローラー：よくわかりません。コントローラーは、MVCモデルで長時間実行され、永続的にアクティブである必要はありません。ただし、PHPフレームワークのコンテキストでは、これらはほとんどがリクエストハンドラです。議論の余地があるものではありませんが、少し流行語のように感じます。

より良い記述子がありますか？PMVCやHMVCのような頭字語が使われるのを見てきました。そこには説明があいまいになっていますが、おそらくこれらは現在のWebフレームワークをあまり目立たなくしているのでしょうか？

あなたはこれを完全に間違った方法で見ていると思います。GUIアプリとWebページは世界的に離れているため、MVCのまったく同じ定義が両方で機能することはありません。MVCはより理想的なものです。ディスプレイやロジックなど、アプリの特定の部分を分離します。

PHP（または一般にWeb）では、ビューはWebページ自体、つまりHTML出力です。定義どおり「ライブ」ではありませんが、リンクをクリックするだけでコントローラーに戻ります（つまり、別のページ要求）。

コントローラとモデルは、あなたが説明したようなものは、違うところです。PHPでは、モデルはデータレイヤーになる傾向があり、データベースと相互作用します。しかし、それでも状況がモデル化されており、ページの読み込みごとに1回だけの場合でも、コントローラーはアプリケーションフローを制御します。

したがって、「Model-View-Controller」という名前は完全に論理的ですが、GUIアプリとWebアプリでは実装が異なります。

私はPHPフレームワークを知らないので、これは低水準言語の観点から見られます。

モデル：

理論的には、モデルは太り、ビジネスロジックを含む必要があります

それは完全にやることです、PHPがこれと何をしているのかわかりません...

モデルは、おそらくデータベースと通信できるPHPのデータクラスであり
、同じモデルまたは部分モデルをJSON形式でクライアントに送信することもできます。

ビジネスロジックとは言えません。データロジック（検証、データベースの相互作用、インポート/エクスポートなど）に似ています。

コントローラーはシンハンドラーである必要があります（入力->出力）

コントローラークラスはモデルクラスとやり取りしますが、実際には薄いです。

出力に基づいて、モデルでいくつかのことを行います...そして、クライアントにModelViewを返します...

実際には、PHPフレームワークは浅いモデルを提唱しています。CIとSymfonyの例は、等価なモデル== ORMです。HTTP入力もコントローラーによって処理され、モデルとして扱われません。

私はそれらのPHPフレームワークについては本当に知りません...

ただし、HTTP入力はコントローラーに到達する前に処理する必要があり
ます。GETおよびPOSTデータを適切なルーティングとパラメーターに変換するクラスを簡単に作成できます。

これはまさにASP.NET MVC 2で発生することであり、問​​題
はありません。これがPHPでどのように発生するかはわかりませんが、密接に関連していると思います。

GETおよびPOSTデータをモデルに簡単に変換することもできます。モデルには、そのためのコンストラクタロジックを含めることができます。または、その目的でいくつかの個別のクラスを追加することもできます。

ビュー：

AJAXが割引された回避策では、Webページにビューを含めることはできません。PHPフレームワークはまだページを送り出します。

なぜそれができなかったのか分かりません、唯一の違いはプロトコルとPHPがJSONを返すことができることなどです...

ページはビューであり、AJAX + JSONを介して要求および更新できます。
繰り返しますが、私はこれらのPHPフレームワークを実際には認識していませんが、ASP.NET MVC 2ではそのように動作します。

インターフェースは通常のHTTPモデルに準拠していますが、MVC以外のアプリケーションに勝る利点はありません。（そして最後に、広く普及しているphpフレームワークのいずれも、実際にはHTMLの代わりにGUIビューに出力できません。Gtk/コンソール/ Webを操作できるPHPライブラリを見たことがありますが、フレームワークはできません。）

あなたが得る唯一の利点（そしてそれは通常のアプリケーションでも同じです）は、モデル（データ）+ビュー（GUI）+コントローラー（ロジック）への分離です。同様に、GUIビューの代わりに実際にHTMLまたはJSONに出力できるC ++フレームワークは表示されません。

コントローラ：

わからない コントローラーは、MVCモデルで長時間実行され、永続的にアクティブである必要はありません。ただし、PHPフレームワークのコンテキストでは、これらはほとんどがリクエストハンドラです。議論の余地があるものではありませんが、少し流行語のように感じます。

MVCは、コントローラーが実行されるソフトウェアアーキテクチャ/パターンであり、どれだけの時間をかけないかです。

しかし、PHP Webアプリはライブビュー（GUI要素）と永続的なコントローラーランタイムでは動作しません。

いいえ、確かにそうです！

AJAXアプリケーションについて考えると、ビューはコントローラーに何かを要求し、部分的なビューを取得します。
このビューまたはデータは、ページのどこかに入力され、ライブ更新されます。

Cookie /セッションを使用できるため、コントローラーも永続的です。

「MVC」は、PHPフレームワークの流行語のように使用されているようです。

MVCはソフトウェアアーキテクチャであり、一部のフレームワークはそれを話題として使用しますが、他のフレームワークは適切に使用します... Wikipediaでいくつかのフレームワークのリストを
参照してください。

MVCはphpプログラミングのSEOだけですか？

MVCとSEOは2つに分かれていますが、そうです... MVCの人気が高まっています。

私の意見では、phpでMVCを使用すると、プログラマーがWebにアクセスできるようになります。MVCの操作方法を知っていると、たとえばJavaからPHPに簡単に移行できます。