Modelli grassi, controller skinny e pattern di progettazione MVC

Ho appena letto un post sul blog che spiega MVC con un’analogia bancaria. Ho alcuni mesi di esperienza nello sviluppo di applicazioni web con un framework MVC (CakePHP), quindi ho le nozioni di base, ma ho iniziato a vedere un tema che mi ha fatto pensare che sto adottando un approccio errato a cui ho messo la mia logica:

  • Modelli grassi, controller magri
  • Mantieni il più ansible la logica di business nei modelli

Nella mia app, i modelli sono anoressici e i controller sono obesi. Ho tutta la logica aziendale nei controller e niente oltre alle associazioni e alle regole di convalida nei modelli.

Scansionando attraverso i miei controller, ora posso identificare molta logica che dovrebbe probabilmente andare in un modello:

  • L’app ha elenchi, che contengono elementi e gli articoli possono essere classificati. La logica di ordinamento che mette la lista in ordine di classificazione è in un controller.
  • Allo stesso modo, gli articoli (modello object) hanno anche immagini (modello immagine). Ogni elemento può avere un’immagine predefinita (designata da image_id nella tabella degli articoli). Quando un object viene visualizzato con le sue immagini, l’immagine predefinita dovrebbe apparire per prima. Ho la logica che fa questo in un controller.
  • Quando viene visualizzata una lista, gli elenchi correlati sono visualizzati nella barra laterale. La logica per determinare quali liste sono correlate è in un controller.

Ora alle mie domande:

  1. Con gli esempi che ho dato sopra, sono sulla buona strada nel pensare che quelle sono istanze di logica attualmente in un controller che appartiene a un modello?
  2. Quali sono alcune altre aree logiche, comuni alle app Web, che dovrebbero entrare nei modelli?
  3. Sono sicuro che identificare questo problema e cambiare il mio schema di progettazione è metà della battaglia, ma anche se deciderò di prendere quegli esempi che ho dato sopra e provare a spostare quella logica su un modello, non saprei da dove cominciare. Qualcuno può indicarmi la giusta direzione postando qualche codice qui o collegando ad alcune buone risorse di apprendimento? L’aiuto specifico di CakePHP sarebbe fantastico, ma sono sicuro che qualsiasi cosa MVC sarà sufficiente.

È un po ‘difficile darti le risposte “giuste”, dato che alcune di esse trattano le specifiche del framework (indipendentemente da quelle con cui stai lavorando).

Almeno in termini di CakePHP:

  1. Tutto ciò che riguarda i dati o la manipolazione dei dati dovrebbe essere in un modello. In termini di CakePHP, che dire di un semplice metodo find ()? … Se esiste la possibilità che faccia qualcosa di “speciale” (cioè richiama un insieme specifico di “condizioni”), che potrebbe essere necessario altrove, è una buona scusa per avvolgere il metodo di un modello.

  2. Sfortunatamente non c’è mai una risposta facile e il refactoring del codice è un processo naturale. A volte ti svegli e basta: “maccheroni santi … che dovrebbero essere nella modella!” (beh forse non lo fai, ma io ho :))

Sto utilizzando almeno questi due “test” per verificare se la mia logica è nel posto giusto:

1) Se scrivo un unittest, è facile creare solo un object “reale” su cui eseguire il test (= l’object che si sta utilizzando in produzione) e non includerne molti altri, ad eccezione forse di alcuni oggetti valore. Avere bisogno sia di un object modello reale che di un object controller reale per eseguire un test potrebbe essere un segnale che è necessario spostare la funzionalità.

2) Ponesi la domanda: cosa succede se ho aggiunto un altro modo per utilizzare queste classi, avrei bisogno di duplicare la funzionalità in un modo che è quasi copia-incolla? … Probabilmente è anche una buona ragione per spostare quella funzionalità.

anche interessante: http://www.martinfowler.com/bliki/AnemicDomainModel.html