Składnik Symfony2 Form - naruszenie MVC i SRP?

Question

Im więcej używam Symfony2 i borykam się z jej formami, tym bardziej dochodzę do wniosku, że są one ogromną przerażającą bestią, która nawet nie powinna istnieć.

Natknąłem się na ten artykuł here i uważam, że zgadzam się z autorem. Nawet jeśli artykuł jest dla Symfony 1.x, wydaje mi się, że nadal ma składnik Form w Symfony2. Wygląda na to, że komponent formularza próbuje rozwiązać problemy, które należą do szablonu, kontrolera i modelu, wszystko w jednym miejscu. Czy to nie stanowi poważnego naruszenia MVC i/lub SRP (zasada jednej odpowiedzialności)?

To może być inna kwestia, ale czuję, że to jest trochę podobne - Mam również zauważyć, że wiele z dostępnych pakietach dla symfony spróbować rozwiązać zobacz kwestie poza widoku, na przykład:

KnpMenuBundle - generujesz menu po stronie serwera z oo-interfejsem (dlaczego nie w widoku warstwy, do której należą?)

IvoryCKEditorBundle - konwersja textarea do ckeditora odbywa się w jednej linii jquery w pliku widoku, więc dlaczego ten pakiet istnieje? Nie chcę nawet policzyć tamtejszej liczby linii.

Wygląda na to, że w Symfony są te naruszenia, czy ja po prostu ich nie dostaję?

Answer 1

Problem z przetwarzaniem formularzy polega na tym, że z definicji narusza to MVC. Jest to problem znany jako "crosscutting" i był badany przez naukę w przeszłości. Na przykład artykuł Domain Driven Web Development With WebJinn jest interesującą lekturą na ten temat.

Jako przykład, myśleć o relacji formy do różnych warstw MVC:

Model:

• Formy replikować strukturę informacyjną swojego modelu domeny (DM). Jeśli zmienisz tę strukturę (np. Dodając pola do struktury danych lub dodając parametry do procedury), musisz także dostosować formularze do wprowadzania tych informacji.
• Potrzebują one informacji o typie z DM, aby przekonwertować dane wejściowe na typy tam wymagane.
• Muszą znać ograniczenia określone w DM, aby zweryfikować dane wejściowe.
• Idealnie odczytują i zapisują dane bezpośrednio z/do DM (np. Odczytując/zapisując pola struktury danych lub wywołując procedurę w DM z przesłanymi wartościami jako parametrami).

Kontroler:

• Formy otrzymują przedstawiły dane i wysłać go do DM.
• Zmieniają one przebieg programu w zależności od tego, czy pomyślnie sprawdzają poprawność, czy też nie.

Widok:?

• Formy renderowanie jako złożoną strukturę znaczników HTML i atrybutów, które zależy od wszystkich wyżej wymienionych (Jeżeli pole jest wymagane powinny być wyświetlane błędy Jak zamówić Pola? Co wybory do zaoferowania w rozwijanej? itd.)

w związku z tym niemożliwe jest napisać mechanizm forma abstrakcji, że nie dotyka wszystkich tych warstw. Przeciwnie, rozwiązanie polega na ustrukturyzowaniu samej biblioteki formularzy zgodnie z MVC, na różne warstwy i podkomponenty, które spełniają SRP. Jeśli zajrzysz do komponentu Symfony2 Form, robi to całkiem nieźle. ;)

Dlaczego więc jest to taka "masywna straszna bestia"? Pierwszym problemem jest abstrakcja. Pomyśl o prostym drop-down na przykład. Jeśli chcemy ponownie użyć kodu dla rozwijanego menu, musimy jakoś go zedytować. Teraz sprawdź powyższą listę, nawet to proste wejście dotyka wszystkich trzech warstw aplikacji MVC. W jaki sposób można streścić coś, co ma być podzielone na trzy różne części?

Drugim problemem jest różnorodność funkcji. Biblioteki formularzy nigdy nie rozwiązują wszystkich problemów napotykanych przez deweloperów w ich codziennym życiu. Zatem wszystkie te warstwy i mechanizmy abstrakcji muszą być rozszerzalne, abyś mógł sprawić, by zachowywały się dokładnie tak, jak chcesz.

Będąc rozszerzalnym, komponent Form już rozwiązuje setki drobnych problemów, o których już nawet nie trzeba myśleć. Jak wprowadzać daty, jak wybrać jedną lub wiele list opcji za pomocą różnych interfejsów użytkownika (listy rozwijane, pola wyboru, przyciski opcji itp.), Jak chronić formularze ponownie lukami w zabezpieczeniach i wiele innych są tematami, które mogę napisać esejami o.

Widzisz, że biblioteki formularzy okazują się dość skomplikowane. Najlepszym sposobem na napisanie takich "masywnych przerażających bestii" jest uczynienie ich API tak prostym, jak to tylko możliwe dla początkujących, jak najbardziej elastycznym dla bardziej zaawansowanych użytkowników i napisanie obszernej dokumentacji na temat wykorzystania jej pełnej mocy. Ostatniego punktu zdecydowanie brakuje (please help!), ale ciągle pracujemy nad wszystkimi powyższymi.

Zredukowanie kompleksu do prostego problemu, z drugiej strony, niestety nie jest możliwe.

A co z innymi bibliotekami formularzy, które są o wiele prostsze? Moim skromnym zdaniem, nie próbują one rozwiązać większości problemów, które komponent Symfony2 Form już rozwiązał. :)

Aktualizacja 24 stycznia 2014: Dla każdego, kto chce wiedzieć więcej (o wiele więcej), oto a paper that I published on the subject.