MVCでは、コントローラーとルーターの違いは何ですか？

それらは同じことを意味しますか（アクションへのURLの添付、またはURLへのアクションの添付）、欠落している違いはありますか？

例：http : //github.com/dannyvankooten/PHP-Router vs. http://konstrukt.dk

ルーター：

ルーティングとは、URIエンドポイント（ベースURLの後に来るURIの一部）を取得し、それをパラメーターに分解して、そのモジュール、コントローラー、およびそのコントローラーのアクションがリクエストを受信するかを決定するプロセスです。

コントローラ：

コントローラーは»コントローラーパターンを実装します。このパターンでは、すべてのリクエストがコントローラーによってインターセプトされ、リクエストされたURL（ルーターからのリクエストのルーティング）に基づいて個々のアクションコントローラーにディスパッチされます。

A フロントエンド・コントローラと協力しなければならないルータやディスパッチャに基づいて決定する（HTTP）リクエストに対するアプリケーション具体的なアクションが実行されなければならないし、それをディスパッチします。

デザインがどのように詳細に応じて、いくつかのコントローラのなしの仕事ルータ Sと彼らは自分のルーティングまたはルーティングは要求が処理される方法を設計に内在するん。

いくつかのディスパッチャのも渡すリクエスト派遣にオブジェクトをアクションメソッド。その後、Action-Methodsはリクエスト自体を部分的に分解するため、コントローラーのアクションでさえ、リクエストに基づいて何らかのルーティングを行うことができます。この典型的な例は、フレームワークが応答としてリダイレクトを行うことを提供する場合です。これは、ルーターとコントローラーがどの程度関連しているか、または近いことも示します。

通常ここに描かれる違いは、ルーティングが実行するアクションメソッドを処理するか、識別するのに役立つことであり、コントローラーはこのアクションを提供する責任がありますが、両方がリクエストを処理します。

ご覧のとおり、ルーターとコントローラーの違いは、実装とフレームワークによって大きく異なる可能性があります。最終的に、具体的なアプリケーションには、特定のレベルの抽象化が役立つか、邪魔になるかどうかのニーズがあります。

ただし、用語からは、コントローラーはアプリケーション全体でより高い役割を果たしていると言えます。これはアクションがそう言うところです。

ルートはURLをコントローラーにマップします。これがアクションです。フレームワークによっては、役割が実際にはあまり分離されていない場合があります。

ルーターはコントローラー層の一部です。ルーターの処理メカニズムは、古い学校のフロントコントローラーパターン（index.phpの大きなスイッチ）を置き換えるものです。

最新のフレームワークでは、ルーターは、可能な種類の要求とそのプロセッサ間の直接接続を定義します。対照的に、コントローラーは識別情報のみを取得し、このデータを独自のコンテキストで解析します。

簡単に言えば、ルーターは通常、GET変数やPOST変数などの外部入力に基づいて、アプリケーションを探索します。

ただし、ルーターはMVCの一部ではなく、いくつかのMVCおよびHMVCフレームワークはルーターを使用しますが、これはそれらをMVCのパターンにバインドしません。

さらに、MVCのいくつかの初期の実装では、実際には、コントローラーごとに1つのファイルを使用して、別々のコントローラーにアクセスするためのファイルベースのアクションの分離に依存していました。これは、より堅牢なモデルを備えたスキニーコントローラーを使用することで、コントローラーの特定のメソッドにスクロールする必要がないため、アプリケーションにはるかに役立ちます。したがって、1か所（モデル）でロジックにアクセスして、振る舞い。

ルータがかかります

要求

どのコントローラー/コントローラーメソッドがリクエストを処理するかを決定します。

コントローラーはリクエストを受け入れて処理します！

また、URLを分割し、ベースURLの後の最初の部分をコントローラーとして使用し、2番目の部分をアクションとして使用するコントローラーも作成しました。これにより、コントローラーに対応するファイルと、アクションに対応するそのファイル内のメソッドがロードされます。

これは実際にはコントローラーではなく（MVCに関する限り）、ルーティングの一部です。

たとえば、[GET] uriを使用します。example.com/ article / view / 123 MVCルーターはuriを解析し、次のセグメントを見つけます。

article view 123デフォルトでは、ほとんどのルーターはarticleControllerをインスタンス化し、パラメーターとして123を渡すviewメソッドを呼び出します。（代わりに、getUriSegment（segmentIdx）メソッドを使用することもできます。これは、フレームワークの設計上の選択です。）

ArticleControllerには、$ articleIdパラメーターを持つviewメソッドがあります。このメソッドはおそらく次のようになります：指定された記事を取得し（たとえば、モデルを介してデータベースから）、それを表示します（おそらく、モデルによって返された記事を与えられたビューを返すことによって）