Symfony 2: pierwsze wrażenia

9 21 października 2010

ioc php symfony

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.