2009-02-11 21 views
9

Attualmente disegno tutti i miei siti Web con un file per ogni pagina, quindi includo elementi comuni come l'intestazione, il piè di pagina e così via. Tuttavia, ho notato che molti framework e CMS usano il pattern del Front Controller.Quali sono i vantaggi e gli svantaggi dell'utilizzo del pattern del controller anteriore?

Quali sono i vantaggi e gli svantaggi dell'utilizzo di un controller anteriore? Il pattern è semplicemente usato in framework e CMS perché non è noto quali pagine esisteranno nel sistema finale?

risposta

10

Srikanth ha una buona risposta. Mi piacerebbe approfondire l'alternativa, però. Supponiamo di avere questa gerarchia URL semplice:

 
/gallery 
/blog 
/admin/login 
/admin/newpost 

Se questo è implementata con i controller pagina (PHP, per esempio), sia gallery.php e blog.php sarà necessario includere alcune common.php all'inizio (o nelle vicinanze). Tuttavia, sia login.php che newpost.php possono includere admin-common.php, che a sua volta inserisce "common.php" e esegue "/ admin /" - impostazioni specifiche, come la verifica che l'utente sia autenticato.

In generale, se si dispone di una gerarchia di URL, risulta molto simile agli alberi di ereditarietà degli oggetti. Tranne che utilizzare l'ereditarietà a livello di lingua, stai ereditando l'ambiente di qualsiasi cosa tu sia foo-common.php che includi.

Non riesco a immaginare come un front controller aumenti la testabilità, alla fine sono necessari gli stessi test di un utente-utente HTTP automatizzato, indipendentemente dall'implementazione.

Uno dei principali svantaggi dei controller di pagina è che rende la tua applicazione web dipendente dal suo ambiente di hosting.Inoltre costringe i tuoi sviluppatori a "vedere" la stessa struttura degli utenti finali, ma ritengo che sia una buona cosa, considerando il numero di siti che vedo avere URL assolutamente atroci.

1

Un vantaggio dell'utilizzo di un controller anteriore è la sua testabilità. se usi TDD è molto più facile testare un controller piuttosto che richiedere un sacco di diversi siti web.

Aggiunto in seguito: Tom: La ragione per cui intendo è più testabile è perché normalmente si implementano i webhandler come classe piuttosto che come pagine del server. e quindi puoi fare un sacco di tetst direttamente sulle classi.

6

riformulare la Wikipedia article on Front Controller:

In una frase - lo si utilizza per evitare la duplicazione.

Un po 'più dettagliato:

controllo anteriore "fornisce un punto di ingresso centralizzato per la gestione delle richieste" Supponiamo che il controller anteriore per la tua app Web sia index.php.

Questo script, index.php, gestirà tutte le attività comuni all'intera applicazione o al framework, come la gestione della sessione , la memorizzazione nella cache, il filtro di input. A seconda dell'input fornito, istanzia quindi ulteriori oggetti e chiama i metodi per gestire l'attività specifica.

L'alternativa a un controller anteriore sarebbe script individuali come login.php e order.php che includessero il codice o gli oggetti comuni a tutte le attività. Ciò richiederebbe una ripetizione del codice di inclusione in ogni script, ma potrebbe anche lasciare più spazio per esigenze specifiche di uno script.

9

Questi sono i motivi per cui non utilizzerei mai un front controller.

  • Abbiamo un controller frontale perfettamente chiamato un browser web.
  • Ogni richiesta http è univoca e separata e deve essere trattata come tale.
  • Non è possibile ridimensionare un'applicazione utilizzando un front controller.
  • Se si interrompe un'applicazione Web in piccoli moduli che sono accoppiati in modo lasco, è più facile testare l'unità/modulo (non testare l'architettura e il controller, ad esempio).
  • Le prestazioni sono migliori se si gestisce una singola richiesta in modo univoco.

Il modello di controller anteriore semplicemente non si adatta a IMHO. Costruisci le applicazioni allo stesso modo di UNIX, rompi un problema più grande in piccole unità che eseguono un compito e svolgi questo compito molto bene. La maggior parte dei framework spinge gli sviluppatori a utilizzare i front controller e sono semplicemente sbagliati.

+1

"Non è possibile ridimensionare un'applicazione utilizzando un front controller." Questo sembra evidente solo per il modo in cui è necessario mappare l'URI alle classi, ma quanto è migliore l'esecuzione del PHP non elaborato una volta che l'accesso ai dati e l'I/O sono stati considerati? –

+3

@FredWilson Il mio punto sul ridimensionamento è che se si utilizza un front controller significa che ogni richiesta va a un singolo punto di ingresso su tutti i server. Se si dispone di punti di ingresso separati per ogni parte di un'applicazione, è possibile ridimensionare ciascun pezzo singolarmente, ad es. un'applicazione di posta elettronica: potresti destinare più server a read-email.php che send-email.php in quanto le persone generalmente leggono le e-mail più frequentemente rispetto a quelle inviate. Questo non può essere raggiunto con un front controller, dovresti scalare tutte le eventualità insieme. – Pete

+0

Questa informazione è ancora pertinente? Framework come Laravel, Zend Framework, Expressive e molti altri sembrano utilizzare esclusivamente il pattern del front controller e il routing direct-to-file viene chiamato "obsoleto" .. (https://stackoverflow.com/questions/48079853/what- sono-queste-instradamento stili cd-in-a-web-application? noredirect = 1 # comment83133888_48079853) – Dennis

Problemi correlati