Significa la stessa cosa (allegando URL alle azioni o azioni agli URL) o c'è qualche differenza che mi manca?
Router:
Il routing è il processo di prendere un endpoint URI (quella parte dell'URI che viene dopo l'URL di base) e scomporlo in parametri per determinare quale modulo, controller e azione di quel controller dovrebbero ricevere la richiesta.
Controller:
Il controllore implementa un modello di controller, in cui tutte le richieste vengono intercettate dal controllore e inviate ai singoli controller di azioni in base all'URL richiesto (ovvero la richiesta di routing dal router).
Un controller di front end dovrebbe collaborare con un router e un dispatcher per decidere in base alla richiesta (HTTP) contro applicazione quale concreto Azione deve essere eseguito e quindi lo invia.
A seconda di quanto dettagliato è un progetto, alcuni Controller funzionano senza router e fanno il il routing proprio o il routing è implicito nella progettazione di come viene elaborata la richiesta.
Alcuni Dispatcher s passano anche un oggetto Richiedi ai metodi di azione inviati . Metodi d'azione quindi si scompongono in parte la richiesta in modo che anche le azioni Controller può ancora eseguire il routing alcuni in base alla richiesta. Un tipico esempio di questo è il caso in cui un framework offre di eseguire un reindirizzamento come risposta. Ciò mostra anche quanto sono correlati o vicini a e Controller
.La differenza che viene normalmente disegnata qui è che il routing si prende cura o aiuta a identificare quale metodo di azione eseguire e il controller è quindi responsabile di fornire questa azione, ma entrambi gestiscono la richiesta.
Come puoi vedere, le differenze tra Router e Controller possono variare notevolmente tra implementazioni e framework. Alla fine, l'applicazione concreta ha i suoi bisogni, indipendentemente dal fatto che un certo livello di astrazione sia utile o ostacoli la strada.
Tuttavia dai termini direi che Controller ha un ruolo più alto nell'applicazione complessiva. Questo è dove l'azione va, per così dire.
Il percorso associa un URL a un controller, che è l'azione. A volte i ruoli non sono realmente separati molto bene a seconda del framework.
I router sono parte di il livello controller. Il meccanismo di elaborazione del router è una sostituzione del pattern di Front Controller della vecchia scuola (il grande interruttore nell'index.php).
In un moderno framework un router definisce una connessione diretta tra un "tipo" di richieste possibili e il suo processore. Al contrario, un controller ottiene solo l'identificazione delle informazioni e analizza questi dati nel proprio contesto.
Semplicemente un router esegue un viaggio attraverso l'applicazione, di solito basato su input esterni come le variabili GET o POST.
Un router non è tuttavia parte di un MVC, diversi framework MVC e HMVC utilizzano router, ma questo non li associa al modello di MVC.
Inoltre, molte delle prime implementazioni di MVC che ho visto si basavano effettivamente sulla separazione delle azioni basata su file con un solo file per controller per l'accesso a controllori separati. Questo serve l'applicazione molto meglio, perché avendo controller skinny, con modelli più robusti, non devi mai scorrere verso un particolare metodo nel controller, e puoi quindi accedere alla logica in un unico punto (il modello), permettendoti di comporre comportamenti.
Il router prende il
richiesta
e decide quali metodi controllore / controllore gestiranno la richiesta.
Il controller accetta le richieste e le gestisce!
Now I've also made controller that splits the url and uses the first part after the base url as controller and second part as action. This loads a file corresponding with the controller and a method within that file corresponding with the action.
Questo non è un vero controller (per quanto riguarda MVC) fa parte del routing.
Ad esempio prendi [GET] uri: example.com/article/view/123 Il router MVC analizzerà l'uri e troverà i seguenti segmenti
articolo vista 123 Di default la maggior parte dei router ora istanzia l'articleController e chiama il suo metodo di visualizzazione passando a 123 come parametro. (In alternativa puoi avere qualche metodo getUriSegment (segmentIdx), questa è una scelta di design per il tuo framework.)
L'ArticleController avrebbe un metodo di visualizzazione con un parametro $ articleId. Questo metodo probabilmente farebbe qualcosa di simile: ottenere l'articolo specificato (da un db tramite un modello per esempio) e quindi visualizzarlo (probabilmente restituendo una vista a cui è stato dato l'articolo restituito dal modello