MVC grandi siti Web, utilizzare un controller ... o molti?

Question

Ho un sito piuttosto grande e sto cercando il modo più efficiente di gestirlo (sono l'unico programmatore).

Sto provando a escogitare una struttura MVC molto semplice (non voglio usare un framework) per aiutare a mantenere tutto il mio codice in ordine.

Per un sito enorme, è meglio avere un solo controller per gestire tutte le pagine, oppure è meglio e più facile dividerli?

Se solo uno, qual è un buon esempio di controller non quadro?

Answer 1

Dividerei tutte le divisioni logiche in controller diversi, se sono tutte pagine statiche, quindi lo serviamo con lo stesso controller di "pagina statica".

Se si dispone di alcune pagine statiche, una pagina di domande frequenti (o una sezione), un elenco di prodotti, utilizzare un controller per ogni sezione diversa. Quindi le pagine statiche verrebbero estratte da un semplice controller da un file flat o da un database, le pagine FAQ verrebbero generate da una tabella delle FAQ da un altro controller, i prodotti e le informazioni sarebbero generati da qualunque sia la fonte.

Ogni volta che viene generata una pagina o si accede ai dati, utilizzare un controller diverso.

Naturalmente, è possibile utilizzare l'ereditarietà di classe per creare la classe base con il codice necessario per qualsiasi controller.

Non sono sicuro che cosa intendi per controller non-framework: controllerò il "framework" di Zend (gasp), il pattern MVC e persino il controller stesso, che possono essere utilizzati separatamente dal resto del framework.

Answer 2

In genere le persone suddividono i controller in controller incentrati su specifiche aree di funzionalità.

Quindi attaccano un "front controller" di fronte a tutto, quindi c'è un solo punto di accesso all'applicazione. L'unico lavoro del front-controller è indirizzare le richieste in arrivo al controller appropriato.

Guarda come è configurato il componente Zend_Controller. Può fornire tutto ciò di cui hai bisogno e sei libero di usarlo senza dover acquistare l'intero Zend Framework.

Answer 3

Dipende da come le altre parti funzioneranno. Se si ha solo un file di modello, probabilmente non vale la pena dividere il controller. Se puoi dividere il modello in sezioni e anche nel controller, fallo.

Tuttavia, spesso trovo che ci sia troppa sovrapposizione tra i modelli per separarli. Si potrebbe avere un modello per gli articoli, ma se si desidera visualizzare i primi 20 articoli in una barra laterale su altre pagine, tale codice dovrebbe essere nel modello dell'articolo - e ne avrete bisogno su ogni pagina.

Onestamente, l'unico modo per farlo è provarlo e vedere. Inizia con un singolo punto di ingresso, e se diventa troppo pesante, rifattalo in pezzi più piccoli.

Answer 4

Un router/dispatcher, molti controller sarebbe il mio consiglio. I controllori devono mappare agli URL, il che significa funzionalità diverse. Un controller collaborerà con diversi servizi per realizzare ogni caso d'uso, quindi un controller per l'intera app diventerebbe troppo pesante se l'app ha più di una serie di casi d'uso.

Answer 5

Tendo a suddividere i controllori in base alla loro responsabilità verso una sezione specifica di un sito/applicazione. Ciò rende il mantenimento del codice molto più semplice. Inoltre, raggruppo i controller (e le viste, i modelli) all'interno dei moduli (cartelle). Ecco un esempio di un progetto in corso su cui sto lavorando:

• Blog
• Messaggi
• Commenti
• Categorie
• Impostazioni
• Messaggi
• Utenti

Più un sito è complesso, più moduli utilizzo. Sebbene la maggior parte dei miei moduli contenga solo un controller 'Index', mi piace l'organizzazione che forniscono.

Quindi utilizzo un router (front controller) che associa un URI di stile REST al modulo/controller/azione appropriato. Es: mysite.com/blog/posts/view/7 chiamerebbe Controller_Posts :: view (7) dal modulo "blog". Un ulteriore vantaggio dell'utilizzo dei moduli è che posso avere URI più specifici rispetto a se non avessi moduli. Anche se suppongo che potrebbe essere risolto utilizzando un router che supporta la definizione di percorsi personalizzati, ma non mi piace troppo.

Come molte altre cose, si riduce a quello con cui sei a tuo agio come sviluppatore, ma probabilmente possiamo essere d'accordo sul fatto che più organizzazione hai, meglio è, finché non complichi le cose .

Per un breve accenno, consiglierei di utilizzare un framework. Capisco se non vuoi usare già uno di quelli là fuori, come ho evitato anche quelli. Ho finito per scrivere il mio, che per l'anno scorso mi ha servito molto bene. È stata una grande esperienza di apprendimento e contiene solo ciò che I desidera/necessità. Detto questo, potresti voler esaminare Kohana e CakePHP - non sono IMO eccessivamente gonfiati e ti faranno sicuramente risparmiare tempo se decidessi di non scrivere il tuo.