In MVC, qual è la differenza tra controller e router?

Significano la stessa cosa (allegando URL alle azioni o azioni agli URL) o c'è qualche differenza che mi manca?

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

Router:

Il routing è il processo di acquisizione di un endpoint URI (quella parte dell'URI che segue l'URL di base) e di scomposizione in parametri per determinare quale modulo, controller e azione di quel controller dovrebbero ricevere la richiesta.

controller:

Il controller implementa un modello »Controller, in cui tutte le richieste vengono intercettate dal controller e inviate ai singoli controller di azione in base all'URL richiesto (ovvero la richiesta di routing dal router).

Un frontend-controller dovrebbe collaborare con un router e un dispatcher per decidere in base alla richiesta (HTTP) rispetto all'applicazione quale azione concreta deve essere eseguita e quindi inviarla.

A seconda di come dettagliato disegno è, un po 'di controller s lavoro senza router s e fanno il percorso da soli o l'instradamento è implicita nella progettazione come la richiesta viene elaborata.

Alcuni Dispatcher s anche passare un Richiesta oggetto al spedito metodi d'azione . Azione-Metodi poi si decompongono se stessi la richiesta , in parte in modo che anche controller azioni ancora in grado di fare un po ' di routing basata sulla richiesta. Un esempio tipico di ciò è il caso in cui un framework offre di reindirizzare come risposta. Questo mostra anche quanto siano collegati o vicini router e controller .

La differenza che viene normalmente tracciata qui è che il routing si occupa 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 le sue esigenze se un certo livello di astrazione è utile o meno.

Tuttavia, in base ai termini, direi che il controller ha un ruolo più importante 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 fanno parte del livello controller. Il meccanismo di elaborazione del router sostituisce il modello di front controller della vecchia scuola (il grande interruttore in index.php).

In un framework moderno un router definisce una connessione diretta tra un "tipo" di possibili richieste e il suo processore. Al contrario, un controller ottiene solo le informazioni di identificazione e analizza questi dati nel proprio contesto.

Molto semplicemente un router elabora un viaggio attraverso l'applicazione, generalmente basato su input esterni come variabili GET o POST.

Un router non fa tuttavia parte di un MVC, diversi framework MVC e HMVC utilizzano router, ma ciò non li lega al modello di MVC.

Inoltre, diverse prime implementazioni di MVC che ho visto in realtà si basavano sulla separazione delle azioni basata su file con un file per controller per accedere a controller separati. Questo serve molto meglio all'applicazione, perché avendo controller skinny, con modelli più robusti, non devi mai scorrere fino a un metodo particolare nel controller e puoi quindi accedere alla logica in un posto (il modello), permettendoti di comporre comportamenti.

Il router prende il

richiesta

e decide quali metodi controller / controller gestiranno la richiesta.

Il controller accetta le richieste e le gestisce!

Ora ho anche creato un controller che divide l'URL e usa la prima parte dopo l'URL di base come controller e la seconda parte come azione. Questo carica un file corrispondente al controller e un metodo all'interno di quel file corrispondente all'azione.

Questo non è in realtà un controller (per quanto riguarda MVC) fa parte del routing.

Ad esempio, prendere l'URI [GET]: example.com/article/view/123 Il router MVC analizzerà l'uri e troverà i seguenti segmenti

view article 123 Per impostazione predefinita, la maggior parte dei router ora crea un'istanza di articleController e chiama il suo metodo view passando 123 come parametro. (In alternativa, potresti avere un metodo getUriSegment (segmentIdx), che è una scelta di progettazione per il tuo framework.)

ArticleController avrebbe un metodo di visualizzazione con un parametro $ articleId. Questo metodo probabilmente farebbe qualcosa del genere: ottenere l'articolo specificato (ad esempio da un db tramite un modello) e quindi visualizzarlo (probabilmente restituendo una vista a cui è stato dato l'articolo restituito dal modello