PHP の MVC パターンを理解するのに役立ちます

PHP の MVC モデルを理解するのに役立ちます
1. 単一の入り口: フロント デスクでのすべてのユーザー リクエストはこの入り口から入ってきますか?
この入り口は通常、index.php ですが、この URL はどうやって入手したのでしょうか?
2.コントローラーに相当するモジュールですか？登録、ログインなどが含まれるユーザー モジュールがある場合、コントローラーに到達する前に URL を解析するプロセスはありますか? URL を解析してユーザーのリクエストを識別し、それがユーザー コントローラーに転送され、コントローラーがリクエストをモデルに転送します。登録とログインを含むクラス (モデル) を作成します。このメソッドを待ちます。それとも 1 つのモジュールが 1 つのコントローラーに対応し、モデル内に個別の登録、ログイン、その他のクラスがありますか?
3. フレームワークといくつかの MVC で書かれたプロジェクトを長い間見てきましたが、MVC がどのように機能するのか、あちこち行ったり来たりして、プロセスがまったく理解できません。

-----解決策--------------------------------
1. 単一の入り口: フロントデスクでのユーザーのリクエストはすべてこの入り口から入りますね?
この入り口は通常、index.php ですが、この URL はどうやって入手したのでしょうか?

一般的には、.htaccess ファイルを介してエントリファイルに制御が渡されます。もちろん、他の方法もあります。

2. コントローラーに相当するモジュールですか。登録、ログインなどが含まれるユーザー モジュールがある場合、コントローラーに到達する前に URL を解析するプロセスはありますか? URL を解析してユーザーのリクエストを識別し、それがユーザー コントローラーに転送され、コントローラーがリクエストをモデルに転送します。登録とログインを含むクラス (モデル) を作成します。このメソッドを待ちます。それとも 1 つのモジュールが 1 つのコントローラーに対応し、モデル内に個別の登録、ログイン、その他のクラスがありますか?

1 つのモジュールが 1 つのコントローラーに対応するわけではありません。これは、コントローラーに到達する前に URL を解析するプロセスが存在するため、業務に応じて設計できます。これは前述の 1 つのエントリで実行され、URL が解析されてどのコントローラを使用するかが決定されます。コントローラーはユーザー データを受け入れ、モデルを呼び出してデータを処理します。その後、コントローラーはモデル処理の結果 (登録やログインなど、コントローラーはユーザー名とパスワードなどを受け入れて、呼び出します) をビューに送信します。モデルがユーザー名やパスワードなどを検証し、コントローラ（検証など）の結果（成功または失敗）が再度ビューに送信されます）。あなたが言及した登録とログインは、実際にはコントローラー内のメソッド（一般にアクションと呼ばれます）ですが、登録とログインの一部のロジック（データのクエリなど）はモデル内で完了します。


3. フレームワークといくつかの MVC で書かれたプロジェクトを長い間見てきましたが、MVC がどのように機能するのかがまだわかりません。プロセスがわかりません。
フレームワーク内の単純なプロセスは一般的に次のとおりです (もちろん、途中に他のものもあり、これは単なる大まかなアイデアです)
リクエスト -> 単一のエントリに移動 -> ルーティング (つまり、解析と呼ばれるもの) URL)->配布->リクエストの処理->完了
------解決策---------
M: モデル モデル
V: ビュー ビュー
C: control control

3. MVC で書かれたフレームワークといくつかのプロジェクトを長い間見てきましたが、MVC がどのように機能するのかまだわかりません。 . このプロセスが本当にわかりません。
「目の見えない人が象に触る」、そうです！
フレームワークはモジュール間の接続を非表示にし、変更可能な一部のリンクのみをユーザーに公開します。フレームワークでプログラムを書くことは、穴埋め問題に答えることに似ています。
これが初心者にフレームワークの使用をお勧めしない理由です

2. コントローラーに相当するモジュールですか?登録、ログインなどが含まれるユーザー モジュールがある場合、コントローラーに到達する前に URL を解析するプロセスはありますか? URL を解析してユーザーのリクエストを識別し、それがユーザー コントローラーに転送され、コントローラーがリクエストをモデルに転送します。登録とログインを含むクラス (モデル) を作成します。このメソッドを待ちます。それとも 1 つのモジュールが 1 つのコントローラーに対応し、モデル内に個別の登録、ログイン、その他のクラスがありますか?
MVC の欠点は、役割分担が明確でないことです
現在、ほとんどのフレームワークはビジネス ロジックを C に置き、データ テーブルの操作を M に置きます
MVC の文字通りの意味では、C は制御と制御のみを担当します。 business ロジックは直接関係ありません
既存のフレームワークを使用する場合は、Mを記述する必要はありません。 M は、フレームワークがプロジェクトを作成するときに、関連するデータベースに基づいてプログラミングを自動的に完了します。あなたのエネルギーは、ビジネス ロジックをコントローラーに分解することだけです

1. 単一の入り口: フロント デスクでのすべてのユーザー リクエストはこの入り口から入ってきますか?
この入り口は通常、index.php ですが、この URL はどうやって入手したのでしょうか?
入口が 1 つであるということは、すべてのユーザー要求がインターフェース ファイルから入力され、すべてのユーザーのニーズがパラメーターとして渡されることを意味します