Coldfusion, qual è il vantaggio del design del front controller rispetto al controller di pagina?

Question

Vengo da un ambiente non informatico e sto cercando di capire come mi avvicino agli approcci di progettazione MVC e ai framework in generale. Io "ottengo" il riutilizzo del codice e la separazione della logica dal display, e "ottengo" l'incapsulamento e il disaccoppiamento, ma non capisco questo.

Al momento ho semplicemente messo tutto in root, una sottocartella separata per immagini, cfcs e _include, tutta l'interazione del database tramite cfcs. Faccio tutte le mie elaborazioni nella parte superiore della pagina, quindi una riga di commento, quindi la visualizzazione/il layout della pagina sotto.

La maggior parte dei quadri che ho guardato sembrano favorire un front controller, quindi la mia versione semplicistica di un controller superiore di progettazione MVC sarebbe una sottocartella per CFC, controller, e punti di vista e un grande switch in index.cfm

<cfif not IsDefined("URL.event")> 
    <cflocation url="index.cfm?event=home" addtoken="No"> 
</cfif> 

<cfswitch expression="#url.event#"> 
    <cfcase value="home"> 
     <cfinclude template="controllers/home.cfm"/> 
     <cfinclude template="views/home.cfm"/> 
    </cfcase> 
    <cfcase value="about"> 
     <cfinclude template="controllers/about.cfm"/> 
     <cfinclude template="views/about.cfm"/> 
    </cfcase> 
</cfswitch> 

.. ma quale vero vantaggio mi dà rispetto al design di un controller di pagina? A meno che non sia solo il tipo di siti che scrivo, sembra sempre che la logica del controller sia specifica per una vista, non è come se un controller potesse adattarsi a più viste o diversi controller potessero produrre in un'unica vista, quindi quale sarebbe il punto di separandoli?

La luce non è ancora arrivata per me, nessun suggerimento?

Answer 1

Con il controller "top", penso si intenda "front" controller, un singolo punto di ingresso per le richieste in un'applicazione. Come ha scritto @bpanulla, la maggior parte dei framework ColdFusion utilizza questo modello di progettazione. Questo diventa particolarmente interessante con URL rewriting, dove diventa facile avere search engine safe URLs intercettando l'URL (ad esempio domain.ext/i/am/friendly.ext) e indirizzarlo a un file standard come index.cfm mentre si rende l'URL richiesto un parametro (spesso come un'intestazione di richiesta). Ciò rende anche le riprogettazioni del sito in cui gli URL cambiano più facilmente perché si prestano bene ad aliasing o reindirizzamenti.

Per quanto riguarda i controller, di solito sono strettamente accoppiati a un particolare URL o pattern URL. È possibile essere più liberamente accoppiati con i controller, ma in pratica trovo che sia una proprietà emergente dopo diversi refactoring. Quello che dovrebbe essere alla base del controller è una o più chiamate a un service layer che parla al database, esegue processi di business, crea entità stateful, ecc ... Quindi il controller riceve le uscite del livello di servizio e le inserisce in qualsiasi meccanismo (ad esempio un event oggetto) è usato per passare i dati alla vista (s).

È il livello di servizio che è destinato a essere riutilizzabile non i controller. I controller sono semplicemente un'estensione di qualsiasi framework all'interno di un'applicazione.L'idea è che dovresti essere in grado di cambiare i quadri con un impatto minimo sulle viste e sul livello di servizio. Il pezzo che deve essere toccato sono i controller.

Quindi un determinato oggetto di servizio in un livello di servizio dovrebbe essere in grado di servire più controllori. Ad esempio, considera la possibilità di mostrare le informazioni degli utenti registrati come widget su un sito. Potrebbero esserci pagine diverse servite da diversi controller, ma ognuno chiamerebbe lo stesso oggetto servizio per ottenere dati utente registrati che presumibilmente potrebbero essere dati alla stessa vista che esegue il rendering del widget.

Aggiornamento: Front Controller Vantaggi

• Sicurezza: autenticazione centralizzata e l'autorizzazione.
• i18n & l10n: iniettare il pacchetto di lingua a destra nella richiesta a livello globale
• Process Orchestration: pensare processo di checkout in più fasi per un carrello della spesa in cui non si desidera che i pulsanti Avanti e indietro e di lavorare - instradando tutto attraverso il front controller siete in grado di far rispettare ciò che passo (cioè lo stato)
• registrazione & monitoraggio: facilmente aggiungere Google Analytics o altra richiesta di monitoraggio a un sito, rendendo l'aggiunta in un solo luogo
• Gestione degli errori: comportamento centralizzata

Ora molti di questi elementi può essere fatto anche utilizzando <cferror> e Appplication.cfc, ma trovo più facile avere un punto centralizzato.

Link Utili

• http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
• http://msdn.microsoft.com/en-us/library/ff648617.aspx

Answer 2

Hai effettivamente implementato il nodo di Fusebox (http://www.fusebox.org/) con quello che hai scritto. Non c'è niente di sbagliato in questo, e la maggior parte della comunità ColdFusion ha usato qualcosa di simile a quello per molti anni - Fusebox era il framework CF più usato (nella mia esperienza) fino a pochi anni fa, quando ModelGlue, Mach-II e l'altro secondo sono stati creati i framework di generazione CF.

Una cosa che posso sottolineare è che il tuo approccio ai controller (come file .cfm) in realtà non impone l'incapsulamento nel tipico modo OOD, con argomenti specifici relativi a una chiamata al metodo dell'oggetto. A meno che non siate estremamente dilligenti, nel tempo i vostri controller .cfm potrebbero accumularsi un numero elevato di parametri non documentati che alterano il comportamento per risolvere un problema o un altro.

Con i vari framework si ottengono anche funzionalità gradevoli come applicazione, sessione e codice specifico di richiesta (onApplicationStart, onRequestEnd, ecc.). Ma puoi sempre ottenerli attraverso un semplice Application.cfc.