Codeigniter / flusso di lavoro MVC

C'è una terza opzione, inizia scrivendo i tuoi test . È l'opzione migliore e non è specifica per MVC. Se inizi a scrivere test, il passaggio successivo dipende dal tuo approccio a MVC:

• Fat controller / skinny models

  I tuoi controllori fanno tutto il lavoro pesante, mentre i tuoi modelli sono essenzialmente POPO , con il compito di mantenere lo stato tra le richieste.

• Controller skinny / modelli grassi

  I tuoi controllori sono limitati a passare roba in giro, la maggior parte (se non tutti) della tua logica di business risiede nei tuoi modelli.

CodeIgniter favorisce il primo approccio ma non vi limita da quest'ultimo. Dipende completamente da te quale seguirai personalmente. Suggerirei caldamente il secondo approccio, semplicemente perché con i modelli grassi avrai la possibilità di testare la tua logica di business molto presto nel ciclo di sviluppo.

Con i modelli skinny, dovrai costruire sia i tuoi controller che i tuoi modelli prima di poter testare la tua logica di business, e questo non è particolarmente efficiente. La tua logica aziendale è la parte più importante della tua applicazione, penso sia ovvio che prima lo costruisci e lo collaudi, meglio è.

Per riassumere, il mio flusso di lavoro è:

1. Scrivi i test della logica aziendale,
2. Scrivi i modelli che soddisfano tali test,
3. Fai finta di praticare TDD per tutto il resto,
4. Scrivi controller e viste.

Ulteriori letture:

• The M in MVC: Perché I modelli sono incompresi e non apprezzati
• Creazione di un modello di dominio - Introduzione all'agnosticismo di persistenza
• Prevenzione del codice Rot 101: Test unitario

• Lavorare nel controller - far funzionare le cose - quindi spingere i metodi sul modello, quindi eseguire il refactoring nel modello, quindi spingere a più di un modello, se necessario.

• La maggior parte degli esperti di CI che ho letto consigliava il modello "magro". un'altra ragione per farlo è l'idea di spingere verso il basso i dettagli specifici dell'implementazione. Il controller dovrebbe essere il più astratto possibile.
  Ad esempio, per fare un modulo una convalida - dice il controllore - "convalidare questo modulo". Non ha bisogno di sapere nulla sul modulo. Quindi, quando il tuo modulo cambia, vai direttamente al modello che funziona con esso.

• Un modo di progettare è per il ruolo utente specifico - Editor, Amministratore, Acquirente, ecc. - la persona che sta usando l'applicazione in quel momento. Quindi, se scopri che le tue classi servono utenti molto diversi (o casi d'uso), è un segno che potrebbero essere difficili da cambiare in futuro.

• DRY è inutile se un nuovo sviluppatore non può leggere il codice e capire cosa sta succedendo. mantieni le cose semplici ed evita la tentazione di mescolare tutto insieme in un solo metodo solo perché è possibile. (si aggiorna! si inserisce! si taglia! si taglia! è un incubo di manutenzione!)

• L'apprendimento della programmazione orientata agli oggetti non dipende dalla lingua. Alcuni dei migliori libri e tutorial su OOP sono in Java. Non importa perché i concetti di base sono molto simili. Non è nemmeno una cosa nuova di zecca in cui devi ottenere l'ultimo libro - ci sono grandi libri OOP che sono stati scritti alcuni anni fa.