Symfony2 Formularkomponente - verletzt MVC und SRP?

Question

Je mehr ich Symfony2 benutze und mit seinen Formen kämpfe, desto mehr komme ich zu dem Schluss, dass sie ein gewaltiges unheimliches Biest sind, das eigentlich nicht existieren sollte.

Ich bin auf diesen Artikel here gekommen und ich finde, dass ich dem Autor zustimme. Auch wenn der Artikel für Symfony 1.x gedacht ist, denke ich, dass er immer noch für die Form-Komponente in Symfony2 gilt. Es sieht wirklich so aus, als ob die Formularkomponente versucht, Probleme, die in die Vorlage, den Controller und das Modell gehören, an einem Ort zu lösen. Verstößt dies nicht ernsthaft gegen die MVC und/oder SRP (Single-Responsibility-Prinzip)?

Dies kann eine andere Frage, aber ich fühle es irgendwie verwandt ist - Ich habe auch bemerkt, dass eine Menge der verfügbaren Bundles für symfony try Ansicht Ausgaben außerhalb der Ansicht, zum Beispiel zu lösen:

KnpMenuBundle - Sie erzeugen Menüs auf der Serverseite mit einer OO-Schnittstelle (warum nicht in der Ansichtsebene, wo sie hingehören?)

IvoryCKEditorBundle - Konvertieren von Textarea in ckeditor erfolgt in einer jquery Zeile in der View-Datei, also warum existiert dieses Bundle? Ich möchte nicht einmal die Anzahl der Zeilen darin zählen.

So scheint es, als ob es diese Verletzungen überall im Kern von Symfony gibt oder bekomme ich es einfach nicht?

Answer 1

Das Problem bei der Formularverarbeitung ist, dass es per Definition gegen MVC verstößt. Dies ist ein Problem, das als "crosscutting" bekannt ist und in der Vergangenheit von der Wissenschaft untersucht wurde. Das Papier Domain Driven Web Development With WebJinn zum Beispiel ist eine interessante Lektüre über das Thema.

Als Beispiel denkt über das Verhältnis von Formen zu den verschiedenen Schichten von MVC:

Modell:

• Forms replizieren die Informationsstruktur Ihres Domänenmodell (DM). Wenn Sie diese Struktur ändern (z. B. durch Hinzufügen von Feldern zu einer Datenstruktur oder durch Hinzufügen von Parametern zu einer Prozedur), müssen Sie auch die Formulare für die Eingabe dieser Informationen anpassen.
• Sie benötigen Typ Informationen von Ihrem DM, um Eingang zu den erforderlichen Typen zu konvertieren.
• Sie müssen die in Ihrem DM angegebenen Einschränkungen kennen, um die Eingabe zu validieren.
• Sie lesen und schreiben idealerweise Daten direkt von/zu Ihrem DM (z. B. durch Lesen/Schreiben von Feldern einer Datenstruktur oder durch Aufrufen einer Prozedur im DM mit den übergebenen Werten als Parameter).

Controller:

• Forms Empfangsdaten vorgelegt und an die DM schicken.
• Sie ändern den Programmablauf abhängig davon, ob sie erfolgreich validiert werden oder nicht.

Ausblick:?

• Forms als eine komplexe Struktur von HTML-Tags und Attribute machen, die (Sollte ein Feld erforderlich werden, um Fehler angezeigt werden auf alle oben hängt Sollte Wie die bestellen Felder? Welche Möglichkeiten in einem Drop-Down bieten? usw.)

Folglich ist es unmöglich eine Form Abstraktion Mechanismus zu schreiben, die nicht alle diese Schichten nicht berührt. Die Lösung besteht im Gegenteil darin, die Formularbibliothek selbst gemäß MVC in verschiedene Schichten und Unterkomponenten zu strukturieren, die die SRP erfüllen. Wenn Sie in die Symfony2 Form-Komponente schauen, ist das ziemlich gut. ;)

Also warum ist es so ein "massives gruseliges Biest"? Das erste Problem ist das der Abstraktion. Denken Sie zum Beispiel an ein einfaches Drop-down-Menü. Wenn wir den Code für das Drop-down wiederverwenden wollen, müssen wir ihn irgendwie abstrahieren. Überprüfen Sie die obige Liste, auch diese einfache Eingabe berührt alle drei Ebenen einer MVC-Anwendung. Wie kann man etwas abstrahieren, das in drei Teile gegliedert werden soll?

Das zweite Problem ist Feature-Vielfalt. Formularbibliotheken lösen nie alle Probleme, denen Entwickler in ihrem täglichen Leben gegenüberstehen. Daher müssen alle diese Ebenen und Abstraktionsmechanismen erweiterbar sein, damit Sie sich so verhalten können, wie Sie es möchten.

Während die Form-Komponente erweiterbar ist, löst sie bereits Hunderte kleiner Probleme, an die Sie nicht einmal mehr denken müssen. Wie man Datumsangaben eingibt, wie man eine oder mehrere Auswahllisten mit verschiedenen UIs (Drop-Downs, Checkboxen, Optionsfelder, etc.) auswählt, wie man Formulare wieder schützt Sicherheitslücken und vieles mehr sind Themen, auf die ich Essays schreiben könnte Über.

Sie sehen, dass Formularbibliotheken ziemlich komplex sind. Die beste Wette, die wir beim Schreiben solcher "massiven gruseligen Bestien" haben, besteht darin, ihre API so einfach wie möglich für Anfänger zu machen, so flexibel wie möglich für fortgeschrittene Benutzer und umfangreiche Dokumentation über die Nutzung ihrer vollen Power zu schreiben. Der letzte Punkt fehlt definitiv noch (please help!), aber wir arbeiten ständig an allen oben genannten Punkten.

Die Reduzierung eines Komplexes auf ein einfaches Problem ist dagegen leider nicht möglich.

Was ist mit anderen Formularbibliotheken, die so viel einfacher sind? Meiner bescheidenen Meinung nach versuchen diese nicht einmal, einen Großteil der Probleme zu lösen, die die Symfony2 Form-Komponente für Sie bereits löst. :)

-Update 24. Januar 2014: Für alle, die mehr wissen (viel mehr) will, ist hier a paper that I published on the subject.