2013-07-01 13 views
12

Sembra che il modo ufficiale per convalidare i modelli in Laravel 4 sia tramite Validator in Controller? Qualcuno può far notare perché è così?Laravel 4 Convalida del modello rispetto alla convalida del controller

Non avrebbe più senso implementare la convalida in Model?

+1

Non direi ufficiale. È solo un modo più semplice di dimostrare che il validatore come l'impostazione di un servizio di validazione decente è un po 'più coinvolto. Esiste un sacco di esempi e pacchetti che eseguono la convalida all'interno del modello stesso o come servizio separato. Guarda in quelli. –

+4

Un vantaggio della convalida del modello è che anche il seeding è convalidato. –

+1

I_would_ say ufficiale perché questo è l'unico modo suggerito dalla documentazione ufficiale. Se questo non è ufficiale, che altro sarebbe? – igorsantos07

risposta

15

Preferisco il pacchetto Ardent per rendere la convalida dei modelli più semplice e minima possibile. Per me ha più senso avere anche le regole di validazione nel modello.

Viene restituito false quando viene chiamato $model->save() e la convalida non riesce, quindi è possibile ottenere i messaggi di errore tramite $model->errors()->all() ad esempio.

+2

Mi sento molto Laravel'ish per me: usa un pacchetto che fa tutto il lavoro duro per te. –

+0

@NiklasModess hai qualche suggerimento su come potrei usare sia Ardent che un altro pacchetto che sto usando che estende Eloquent per consentire un ORM MongoDB? Il mio modello estende il modello creato da questo altro pacchetto. – Thelonias

+0

@NiklasModess, conosci qualche pacchetto che consente ai miei modelli di essere sia modelli Ardent che modelli MongoDB? – Thelonias

5

Ha senso convalidare i modelli, ma questa convalida dovrebbe essere solo lì per assicurarsi di non salvare alcun dato corrotto.

Validator è nello Controller perché è utilizzato per gestire Input e generare Output. Se si esegue la convalida nello Model, è necessario restituire false e mostrare all'utente i messaggi di errore più casuali relativi ai dati non validi. Si potrebbe anche restituire qualche kine di array contenente tutti gli errori che vengono generati, ma questo è qualcosa che un Modello non dovrebbe fare. Oppure potresti lanciare un'eccezione, operazione che dovrebbe essere eseguita quando un modello tenta di utilizzare dati non validi, ma uccide l'applicazione, che non è la soluzione desiderata per un validatore di moduli.

Quando si esegue la convalida del modulo nel controller, è possibile eseguire tutto ciò che si desidera con i messaggi di errore, senza modificare lo scopo di un modello.

E nel modello è possibile eseguire una convalida per accertarsi di non aver commesso errori, il che danneggerebbe il database. Perché se questo accade, l'applicazione dovrebbe spegnersi.

Quindi, per mettere questo in una risposta reale alla tua domanda: La convalida nel modello ha senso per evitare i dati corrotti, ma se si desidera dare un feedback all'utente di input non valido, dovrebbe essere nel controller.

+7

Penso che definire le regole di validazione in un solo punto e non in più punti (il modello, il controller, il modulo front-end) sia la chiave qui. Il modello è l'unica cosa comune in questo scenario. – Jason

+0

perché "non dovrebbe" il modello contiene i propri messaggi di errore? se pensate a modelli come wrapper per il vostro DB, quando provate a inserire dati non validi nel vostro DB SQL vi restituirete un messaggio di errore, perché non lasciare che anche i modelli lo facciano? –

2

Ho lottato con questo per un po 'e ho deciso di gestire la maggior parte della mia convalida in un servizio di validazione, basandomi su qualcosa come this. Posso quindi avere diverse regole di convalida basate sul contesto.

Come indica Nico, la convalida nel modello è buona per evitare dati corrotti, ma io preferisco i controller sottili in modo da passare la funzionalità che si inserirà nel controller nel servizio. Ciò ha anche il vantaggio di poter riutilizzare la validazione in diversi controller/metodi.

0

Perché preferisco Convalida in modello: Ho lavorato con entrambi gli stili e ognuno ha vantaggi e svantaggi, ma preferisco la convalida in-model. Nella nostra attuale app non vedo la convalida del controller come opzione, dal momento che stiamo modificando i nostri dati in così tanti luoghi (moduli dedicati, modifica in linea, modifica collettiva, caricamento collettivo, API, ecc.). Non ho mai lavorato veramente con i servizi di validazione (anche se potrebbero essere un'opzione), ma personalmente mi piace mantenere la logica il più vicino possibile al modello, in questo modo so che un altro sviluppatore non lo ignorerà. Inoltre, non mi piace aggiungere molti file aggiuntivi sopra la cartella MVC e librerie di base perché sembra più che devi pensare di organizzare correttamente.

Problemi con Convalida in modello: Queste sono alcune cose che è necessario considerare per fare in-Model bene. Alcuni di questi sono già stati presi in considerazione dai PLUGINS. Penso che altri framework (CakePHP) li trattino già, ma Laravel non lo fa davvero.

  1. valori che saranno convalidati ma non salvato al db (ad esempio, "accepted_agreement").
  2. molti a molti o appartiene a molti rapporti
  3. impostazione di default condizionali (non critici ma potrebbe desiderare di pensare allo stesso tempo)
  4. diversi scenari di forma - a volte potrebbe essere necessario convalida diverso a seconda di quale modulo lo invia. Il riferimento al modulo può essere un attributo purgeable forse per validazione?
  5. Come si recuperano i messaggi di errore (tutti i plugin di convalida in-model gestiscono ciò per te)
  6. Set di regole di convalida diversi. Bozza di creazione rispetto alla creazione "reale". (La maggior parte gestire questo per voi)

In definitiva, per le applicazioni semplici che non hanno un sacco di modi di interagire con il modello, direi che la convalida del controller può essere più semplice, altri poi che preferisco in -modello.

Problemi correlati