Componente Symfony2 - violando MVC e SRP?

Question

Più uso Symfony2 e lotto con le sue forme, più arrivo alla conclusione che sono una bestia spaventosa e massiccia che non dovrebbe nemmeno esistere davvero.

Mi sono imbattuto in questo articolo here e trovo che sono d'accordo con l'autore. Anche se l'articolo è per Symfony 1.x, penso che valga ancora per il componente Form in Symfony2. Sembra davvero che il componente del modulo cerchi di risolvere i problemi che appartengono al modello, al controller e al modello, tutto in un unico posto. Questo non viola gravemente l'MVC e/o SRP (principio di responsabilità singola)?

Questa può essere una questione diversa, ma sento che è sorta di correlato - Ho anche notato che molti dei fasci disponibili per symfony cercare di risolvere i problemi di vista al di fuori della vista, per esempio:

KnpMenuBundle - generi menu sul lato server con un'interfaccia oo (perché non nel livello vista a cui appartengono?)

IvoryCKEditorBundle - la conversione della textarea in ckeditor avviene in una riga jquery nel file di visualizzazione, quindi perché questo bundle esiste? Non voglio nemmeno contare il numero di linee lì dentro.

Quindi sembra che ci siano queste violazioni ovunque nel nucleo di Symfony o semplicemente non lo capisco?

Answer 1

Il problema dell'elaborazione dei moduli è che viola MVC per definizione. Questo è un problema noto come "crosscutting" ed è stato studiato dalla scienza in passato. Il documento Domain Driven Web Development With WebJinn, ad esempio, è una lettura interessante sull'argomento.

A titolo di esempio, pensare al rapporto tra forme ai diversi strati di MVC:

Modello:

• Forme replicano la struttura informativa del vostro modello di dominio (DM). Se modifichi questa struttura (ad esempio aggiungendo campi a una struttura dati o aggiungendo parametri a una procedura), devi anche adattare i moduli per l'immissione di tali informazioni.
• Sono necessarie le informazioni sul tipo dal DM per convertire l'input nei tipi richiesti.
• Devono conoscere i limiti specificati nel DM per convalidare l'input.
• Idealmente leggono e scrivono dati direttamente da/verso il vostro DM (ad esempio leggendo/scrivendo campi di una struttura dati o invocando una procedura nel DM con i valori inviati come parametri).

Controller:

• Forms ricevono presentati i dati e li inviano al DM.
• Modificano il flusso del programma a seconda che siano validi o meno.

Vista:??

• Forme rendono come una struttura complessa di tag HTML e gli attributi che dipende tutto quanto sopra (Nel caso di un campo richiesto dovrebbe essere visualizzato errori Come ordinare il campi? Quali scelte per offrire in un menu a discesa? ecc)

di conseguenza, è impossibile per scrivere un meccanismo di forma di astrazione che non tocca tutti questi strati. La soluzione, al contrario, è strutturare la stessa libreria di moduli in base a MVC, in diversi livelli e sottocomponenti che soddisfano l'SRP. Se si esamina il componente Symfony2 Form, lo fa abbastanza bene. ;)

Quindi perché è una "bestia spaventosa enorme"? Il primo problema è quello dell'astrazione. Pensa ad un semplice menu a discesa, ad esempio. Se vogliamo riutilizzare il codice per il menu a discesa, dobbiamo in qualche modo astrarlo. Ora controlla la lista qui sopra, anche questo semplice input tocca tutti e tre i livelli di un'applicazione MVC. Come puoi astrarre qualcosa che deve essere strutturato in tre parti differenti?

Il secondo problema è la diversità delle funzionalità. Le librerie di moduli non risolvono mai tutti i problemi che gli sviluppatori affrontano nella loro vita quotidiana. Quindi tutti questi livelli e questi meccanismi di astrazione devono essere estensibili in modo che possiate farli comportare esattamente come volete.

Pur essendo estendibile, il componente Form risolve già centinaia di piccoli problemi a cui non devi più pensare. Come inserire le date, come selezionare una o più di una lista di scelte usando diverse UI (menu a tendina, checkbox, pulsanti di opzione, ecc.), Come proteggere nuovamente i moduli e molti altri argomenti che potrei scrivere saggi di.

Si vede che le librerie di moduli risultano piuttosto complesse. La migliore scommessa che abbiamo nello scrivere queste "bestie spaventose" è rendere le loro API il più semplici possibile per i principianti, il più flessibile possibile per gli utenti più avanzati e scrivere un'ampia documentazione su come sfruttarne appieno la potenza. L'ultimo punto è sicuramente ancora carente (please help!), ma lavoriamo continuamente su tutto quanto sopra.

La riduzione di un complesso a un problema semplice, d'altro canto, non è purtroppo possibile.

Che dire di altre librerie di moduli là fuori che sono molto più semplici? A mio modesto parere, questi non cercano nemmeno di risolvere la maggior parte dei problemi che il componente Symfony2 Form risolve già per te. :)

Aggiornamento 24 gennaio 2014: Per tutti coloro che vogliono saperne di più (molto di più), ecco a paper that I published on the subject.