Symfony 2: pierwsze wrażenia

Nowości w Symfony 2

PHP 5.3 jako standard i korzystanie z przestrzeni nazw
Zupełnie nowy kod, zdecydowane odchudzenie klas, czuć lekkość
Dependency Injection (IoC)
Events
Modułowa architektura, nie tylko pod postacią katalogów o nazwie modules/plugin
Rezygnacja z pluginów jako mikroaplikacji na rzecz Bundles
Źródła hostowane na GitHub

Bundle 1: Marketing

Prezentacje, konferencje, świetny design stron przemawiają za rewolucyjnością nowego produktu SensioLabs.

Faktycznie, w świecie PHP może być to jakaś rewolucja, ale chyba głównie za sprawą samego PHP 5.3 i namespaces zaciągniętych z "szóstki". A źrodła Symfony? Ano jak to PHP - trochę Javy trochę C, np. klasy Request/Response w których zaimplementowano tylko akcesory (powstają obiekty o niezmiennym stanie). W Django najważniejsze middleware opierają się na możliwości modyfikacji obiektu Request dodając np. właściwość user. Proste i dziala. W Symfony 2 to nie przejdzie, ubijany jest dynamizm języka programowania.

Bundle 2: Dependency Injection

Kiedyś bardzo potrzebowałem takiego mechanizmu. Otóż za pomocą konfiguracji (PHP/Yaml/XML/etc) można zdefiniować skonfigurowane usługi pod unikalnymi nazwami. Konfiguracja może odbywać się przez wstrzyknięcie argumentów do konstruktora lub wybranych metod (argumentami mogą być wartości lub odwołania do innych zdefiniowanych usług).

W teorii można swobodnie wymieniać/parametryzować poszczególne instancje klas. W praktyce stosuje się to rzadko lub wcale.

Popełniłem kiedyś taki plugin do Symfony 1.x - sfIocPlugin - wzorowałem się na IoC ze Springa. ''' Dependency Injection w Symfony może przydać się przy większych projektach, gdzie pewne usługi mogą być wymienialne w zależności od wdrożenia. Osobiście jednak uważam, że realizacja "większych projektów" w PHP to utopia. Może komuś się to jednak przyda.

EDIT: Dependency Injection sprawdza się w unit testach (o ile środowisko unit testów umożliwia użycie DI), szczegóknie w połączeniu z mock-objects.

Bundle 3: Events

System zdarzeń w Symfony 2 jest prosty. Jest dość dobrą realizacją wzorca obserwatora. Autor przyznaje, że wzorował się na notyfikacjach z Cococa.

Implementacja ta przypomina mi naszego firmowego EventBrokera napisanego chyba w 2006 roku. Osobiście wolę django.signals z racji rejestrowania obserwatora do konkretnej instancji sygnału. Z kolei w Symfony obserwator (listener) rejestrowany jest w instancji dispatchera podając nazwę sygnału.

Nasuwają się dwie wady (z doświadczenia):

dispatcher może nie mieć zarejestrowanego zdarzenia (trzeba znaleźć odpowiedni dispatcher, przez który będzie przebiegał event),
rejestracja i notyfikacje odbywają się przez nazwę - robiąc literówkę przy connect nie mamy szans na informacje o błędzie; takie błędy znajduje się zwykle po kilku godzinach.

Bundle 4: Super wydajność

Wydajność została zwiększona, ale nie uważam że o te mityczne 2.5x.

Benchmark strony "Congratulations..." (index.php) z sandboxa, dla ab -c 100 -n 1000:

Symfony 2: 32.18 [#/sec]
Symfony 1.2: 19.58 [#/sec]

To jest nieco powyżej 1.5x. Żeby jednak trochę podrasować wersję 1.2 wyłączyłem w settings.yml użycie bazy danych (test Symfony 2 też nie używał BD).

Widok o podobnej złożoności w Django serwowany jest nawet do 200 rq/sec. Strona główna portalu opartym na Django (z użyciem memcache) jest serwowana w trybie developerskim w porywach do 160 req/sec.

Wydajność Symfony 2 nie zachwyca.

Bundle 5: Formularze

Czytałem tylko kod. Są to niemal te same nieudolne formularze, o których już pisałem - Symfony forms vs Django forms.

Podsumowanie

Szkoda czasu.

Komentarze

sdcsdcsdc, Kwiecień 25, 2011 1:25 rano napisał:

Kolejny fanboj ;)
autor, Kwiecień 25, 2011 11:38 rano napisał:

masz w ogole cos do powiedzenia w tym temacie?
makerlabs, Wrz. 14, 2011 12:22 po południu napisał:

Porównywanie framework'ów z dwóch różnych języków nie jest miarodajne... debat ma temat python i php było wiele... każdy z tych języków ma swoje zalety i wady. Jeżeli chodzi o sam framework symfony2 jest to duży krok na przód w stosunku do pozostałych framework'ów (mówiąc stricte o php). Symfony2 pożycza wiele dobrych rozwiązań z innych języków bo niestety jedną z wiekszych wad php jest jego powolna ewolucja co powoduje liczne ograniczenia i z reguły złe nawyki programistyczne. Ja z aktualnego doświadcze i aktualnieia mogę powiedzieć, że symfony2 prezentuje się naprawdę obiecująco na tle innych framework'ów php i aktualnie wykorzystuje go do własnych projektów.
autor, Paź. 12, 2011 12:01 rano napisał:

SF2 to faktycznie krok w przód (w świecie PHP). Jednak z pośród wielu dostępnych narzędzi wolę wybrać lepsze, trwalsze, może bardziej przyszłościowe, rozszerzalne czy uniwersalne. Stąd Python (ogólne przeznaczenie), stąd Django (web). Jednak w tym wpisie nie przyrównywałem SF2 do Django za wyjątkiem notki o wydajności, że można jednak w dziedzinie web developmentu osiągnąć lepsze rezultaty lepszymi narzędziami. Raczej wskazałem na kilka zaganień, które schrzaniono w SF2. Argumentowałem wady event dispatchera oraz formsów. Wydajność ma drugorzędne znaczenie, ale starałem się obalić mit jej 2.5-krotnego wzrostu. Dostrzegłem też zalety SF2. Może ze mnie "fanboj", ale mam mniej stresu, więcej czasu na relaks i inne projekty. W dobie popularności railsów i django troche śmieszy mnie szum wokół SF - nie oferuje nic, czego nie można zrobić szybciej czy wygodniej. Na zakończenie dodam, iż mimo krytycznej oceny SF podziwiam i doceniam Fabiena. Łebski gość. A że SF nie dla mnie? Mój wybór.
Marek, Kwiecień 27, 2012 6:41 po południu napisał:

A taki youporn.com to nie jest czasem ten "większy projekt"?
Marek, Kwiecień 27, 2012 6:47 po południu napisał:

Jeśli chodzi o klasę Request, to bardzo dobrze, że nie pakuje się tam atrybutów typu user itp. Symfony2 został zbudowany w oparciu o specyfikację HTTP, obiekt żądania reprezentuję obiektową abstrakcję żądanie HTTP i tę funkcję spełnia doskonale, ale że Ty masz taki nawyk ze stosowania Django to już Sf2 nie wiń.
autor, Kwiecień 27, 2012 7:32 po południu napisał:

@Request: Czy zatem obiektowa abstrakcja SF2 na przykłądzie $this->getRequest()->getSession() w kontrze do request.session w Django jest zgodna ze specyfikacją HTTP? Przyczepiłem się do implementacji z mutatorami/akcesorami zbędnymi w dynamicznym języku programowania. To jest zbędny narzut. @Youporn: nie znam specyfikacji tegp projektu. Spróbuj, może Ci się uda. Ostatnio publikowano speca do oryginalnego Prince of Persia na Apple - możemy pogadać.
Marek, Kwiecień 28, 2012 1:01 po południu napisał:

Spec youporn: http://highscalability.com/blog/2012/4/2/youporn-targeting-200-million-views-a-day-and-beyond.html "Przyczepiłem się do implementacji z mutatorami/akcesorami zbędnymi w dynamicznym języku programowania. To jest zbędny narzut." To twoja opinia, wyrobiona pewnie po latach używania Pythona, po czymś takim frameworka się po prostu nie ocenia. Dzięki za przykład z getSession(), choć dla mnie to jest raczej ok, choć kiedyś dokładnie się temu przyjrzę i napiszę coś więcej na blogu, który mam nadzieję założyć niebawem. Pozdrawiam
autor, Kwiecień 28, 2012 5:50 po południu napisał:

@youporn: dzięki za link. Główny ich problem to streaming. PHP+FPM wraz z mocnym cache załatwiają dobrą responsywność serwisu. Nie znam FPM i już o jego zaletowadach nie przekonam się. Dependency injection - oprócz stwierdzenia, że jest fajne nie napisano o konkretnym zastosowaniu. Moja opinia o dynamiźmie języka ukształtowała się po latach używania (tj. intensywnego programowania w) PHP, choć Python posłużył do porównania Powodzenia w blogowanu. Czytalności życzę.

Tematy

Projekty opensource

Google Chrome extensions

Prawdy i mity

Polecam