Zend Framework
Ta platforma jest oficjalnym projektem Zend Company, izraelsko-amerykańskiej firmy zajmującej się rozwojem języka PHP. Projekt powstał w okolicach 2005 roku jako odpowiedź na pojawienie się Ruby On Rails oraz brak analogicznego narzędzia dla PHP trzymającego odpowiednie standardy. Mimo iż na początku był niesamowicie wybrakowany i nie posiadał często nawet podstawowych komponentów takich, jak obsługa formularzy, odniósł duży sukces. Dzięki promocji kojarzy go przynajmniej z nazwy praktycznie każdy nieco bardziej ogarnięty programista PHP bez względu na swoje pochodzenie. Nazywany był biblioteką do tworzenia frameworków, gdyż de facto aby zrobić jakąś aplikację, trzeba go było sobie najpierw poskładać z komponentów. Jak to wygląda obecnie? Przekonajmy się.
Poziom trudności
6 lat temu Andi Gutmans pisał na swoim blogu, że "celem projektowym ZF-u jest maksymalna prostota". Jednak oprócz tego przyjęte zostały także inne założenia projektowe, które z tą prostotą się nieco kłóciły. W efekcie powstała platforma o dużych możliwościach i skalowalności, ale który wymaga od programisty więcej niż konkurencyjne rozwiązania, zarówno od strony umiejętności, jak i czasu niezbędnego na jego poznanie. Niemniej jeśli ktoś pisał już w czymś innym, odnajdzie się w projekcie stosunkowo szybko. Mamy tu klasyczną wręcz implementację MVP z pasywnym widokiem, zgodnie z tradycją, a niezgodnie z nauką nazywaną "MVC", mamy routery, mamy akcje i wszystko, co da się spotkać gdzie indziej.
Prawdziwa zabawa zaczyna się dopiero wtedy, gdy chcemy dostosować ZF-a do swoich potrzeb i swojej filozofii kodowania. Tak, ta platforma nam na to jak najbardziej pozwala, ale właśnie tutaj trzeba już przysiąść nad kodem i zagłębić się w czeluściach obszernej dokumentacji...
Architektura
Zend Framework o wiele lepiej jest rozpatrywać jako obszerny zbiór różnorodnych komponentów dostarczających różnych funkcjonalności platform WWW. W początkowym okresie swego istnienia faktycznie był on takim zbiorem, przez co de facto programista musiał sobie sam go poskładać do kupy, aby zbudować jakąś aplikację. Definicja platformy mówi, że to ona, a nie programista, zarządza przepływem sterowania w aplikacji. Tymczasem narzędzia do automatycznego generowania kodu czy wbudowane zarządzanie procesem uruchamiania pojawiły się dopiero w ostatnich wersjach.
Zejdźmy teraz nieco niżej, aby przyjrzeć się, jak wygląda budowanie aplikacji. Jak już wspomniałem, mamy tutaj klasyczną implementację wzorca architektonicznego MVP z pasywnym widokiem, czyli widoki w formie szablonów, jakiś ORM i całą resztę rzeczy w klasach zwanych kontrolerami, które z kolei dzielą się na akcje. W przeciwieństwie do omawianego poprzednio Symfony, struktura ta jest bardziej elastyczna. De facto modelem może być tutaj cokolwiek. ZF posiada jakąś swoją warstwę abstrakcji bazy danych, ale niedawno ogłoszono, że zostanie ona niebawem zastąpiona przez Doctrine. Ja osobiście bez problemu łączyłem Doctrine już ze wcześniejszymi wersjami ZF-a i jedyne, co musiałem tak naprawdę zrobić, to napisać własną obsługę sesji. Poza tym nie było większych problemów z integracją.
Obsługę szablonów zapewnia komponent Zend_View, który jest zwyczajnym systemem szablonów, który używa PHP jako języka do ich tworzenia. Towarzyszy mu armia rozmaitych helperów, lecz poza tym pisze się w tym dokładnie tak samo, jak w każdym innym systemie szablonów o identycznej budowie. Zależności jednak nie są tu aż tak silne. W Symfony 1.x prawdę mówiąc bałbym się trochę integrować np. Open Power Template'a, tymczasem tutaj nie tylko się nie bałem, ale po prostu taki port bez większych problemów stworzyłem. Działa? Działa, nawet oryginalne helpery da się w zdecydowanej większości przypadków wykorzystać.
Jeśli chodzi o strukturę samej aplikacji, z racji braku odpowiednich mechanizmów w przeszłości nie było narzuconego żadnego schematu jej organizacji. To do nas należało skonfigurowanie front controllera, powiadomienie go, gdzie trzymamy nasze "kontrolery" i akcje, powiadomienie o miejscu składowania konfiguracji itd. De facto, jeśli się uprzemy, to dalej możemy pisać właśnie w ten sposób. Gdy ZF zaczął dostarczać odpowiednie wsparcie, moja przygoda z nim dobiegała już jednak końca, tj. miałem już dobrze rozwinięty projekt, który musiałem po prostu utrzymywać, a nie przepisywać na nowo. Z tego powodu nie mogę zbyt wiele powiedzieć o nowej strukturze, aczkolwiek warto dodać, że wraz z nią pojawiło się w końcu wsparcie dla odpowiedników "aplikacji" w Symfony, czyli możliwość... podzielenia aplikacji na front-end i back-end. Aby uzyskać taki efekt we wcześniejszych wersjach, trzeba było się trochę pobawić.
Elastyczność
Nie napiszę zbyt wiele o ORM-ie i widoku, jak w Symfony z jednego prozaicznego powodu. Pierwsze, co zrobiłem po rozpoczęciu pracy z tą platformą, to zainstalowałem w niej Doctrine i Open Power Template'a. Dużą zaletą Zend Frameworka jest możliwość jego łatwej przebudowy i dostosowywania do własnych potrzeb. Nie pasuje nam jakiś komponent? Proszę bardzo, siadamy i piszemy własny. Wystarczy, że zaimplementujemy jeden, dwa interfejsy i nasze rozwiązanie zaczyna bez trudu współpracować z resztą platformy. No, może z tą bezproblemowością to trochę przesadziłem, bowiem zależności faktycznie jest dość sporo, niemniej jak się uprzemy, jesteśmy w stanie to zrobić. Kluczem to tej elastyczności jest sama organizacja interfejsu programistycznego, która owszem, jest lekko ociężała, ale ma jedną niezaprzeczalną zaletę: jest bardzo dobrze zdefiniowana i trzyma się reguł projektowania obiektowego. Nie uświadczymy tutaj czegoś takiego, że klasa stronicowania jest dostosowana wyłącznie do współpracy z ORM-ami i na dokładkę jest jeszcze abstrakcyjna. O nie, tutaj mamy porządny mechanizm zaprojektowany zgodnie z zasadą jednej odpowiedzialności, który z konkretnym źródłem danych łączy się przy pomocy wzorca adapter. I to rozumiem!
Magia i jakość kodu
W Zend Frameworku także występuje trochę elementów magicznych. Nie są one jednak aż tak nachalne, jak w Symfony, a ponadto dzięki dobrej jakości kodu nawet jakoś to działa. Z drugiej strony, magia zawsze magią pozostanie i jak coś się zepsuje, to aplikacja sypie się dokumentnie. Od strony wewnętrznej kod jest nieźle napisany. Trzyma się sensownych standardów kodowania oraz poziomów jakości, aczkolwiek aktu masochizmu w postaci używania spacji zamiast tabulacji chyba nigdy już nie pojmę. Dużą zaletą jest wysoki poziom pokrycia kodu testami. Aby cokolwiek znalazło się w ZF-ie, musi być przetestowane, a efekt jest taki, że o ile w Symfony w trakcie trwania jednego projektu znalazłem ze dwa błędy (a w Doctrine z 15), to nie przypominam sobie w tej chwili, bym znalazł coś poważniejszego kiedykolwiek w ZF-ie.
Wydajność
Zend Framework również nie należy do najwydajniejszych frameworków, aczkolwiek odnoszę subiektywne wrażenie, że pracuje szybciej, niż Symfony. Na pewno jest to prawda dla trybu developerskiego :) lecz tryb produkcyjny pominę milczeniem. Dużym zagrożeniem dla wydajności ZF-a jest to, co projektanci robią z komponentami. Bardzo często się zdarzało, że najpierw czegoś bardzo potrzebnego bardzo długo nie było, a gdy się to w końcu pojawiło, programistom fundowana była gigantyczna kobyła, w której implementowano nawet najbardziej kretyńskie funkcjonalności. Dobrym przykładem jest tutaj Zend_Loader. Na początku była to prosta ładowarka klas, która jednak nie była dobrze skalowalna i prawdę mówiąc nigdy jej nie używałem, bo się zwyczajnie nie dało. Programiści długo na to narzekali i w wersji 1.9 dostali reimplementację... o matko, czego to tam nie ma! Nowe wcielenie na nazwie klasy wykonuje chyba więcej operacji, niż parser PHP podczas kompilowania skryptu. Jest tam nawet funkcjonalność, która pozwala na konfigurowanie, której wersji Zend Frameworka używać, w zamyśle by móc testować zgodność z kilkoma. No fajnie, tylko na litość... jakbym czegoś takiego potrzebował, to bym jedną zmienną po prostu nazwę katalogu zmieniał w każdej normalnej ładowarce. Zend_Loader jest więc obecnie prawdopodobnie najwolniejszą ładowarką klas na świecie, jaka kiedykolwiek została stworzona.
Dokumentacja, wsparcie...
Tutaj ZF-owi należy się duży plus. Dokumentacja jest rozbudowana, szczegółowo omawiając każdy komponent. Sporo programistów mówi, że jest tam wszystko, tylko nie to, co potrzeba, ale tutaj jednak, zwłaszcza po doświadczeniach z Symfony, zgodzić się ostatecznie nie mogę. Dokumentacja ZF-a dotyka zagadnienia z różnych stron, w tym także z punktu widzenia osoby, która chce coś sobie przerobić. Dlatego obok wprowadzenia mamy także omówienie dokładnej zasady działania i możliwości rozbudowy, a duża część potrzebnych interfejsów jest elegancko opisana. Kontrastuje z tym niestety poziom dokumentacji API, która często wygląda tak:
/** * Sets the crephelion vector adjustment. * * @param int $adjustment */ public function setCrephelionVectorAdjustment($adjustment) { // ... }
Po przeczytaniu opisu w API jestem dokładnie tak samo mądry, jak wcześniej i szkoda, że nikt nie pokusi się już o objaśnienie, co to jest "crephelion vector" i po co należy mu ustawić jakiś "adjustment". Problem ten jest poważniejszy, gdy wgryzamy się głębiej w szczegóły budowy.
W dokumentacji brakuje także jakiegoś szerszego wprowadzenia, które krok po kroku pokazuje budowę typowej aplikacji tak, by można było sobie te komponenty poukładać. Okazuje się więc, że mamy sytuację niemal dokładnie odwrotną, jak w Symfony. Tam cała dokumentacja była de facto taką książką "jak zbudować cośtam", która pomijała połowę istotnych rzeczy, tu z kolei mamy dokładny opis każdego komponentu, ale bez jakiegoś przewodnika, jak to wszystko złączyć. Na szczęście społeczność ZF-a jest bardzo aktywna i nawet na polskiej planecie PHP można poczytać sporo na ten temat.
Zastosowanie
Zend Framework na pewno nie jest platformą do prościutkich CMS-ów klepanych hurtem dla rozmaitych klientów. Z drugiej strony, moim zdaniem dużo lepiej od Symfony nadaje się do budowy bardziej złożonych i nietypowych aplikacji. Mimo braków, mimo ociężałości niektórych komponentów jesteśmy w stanie tutaj stosunkowo szybko dostosować to, co nam nie odpowiada, do własnych potrzeb, przerobić lub zaimplementować jakiś komponent tak, by współpracował on później z całą resztą. Jest również bardziej przewidywalny, co przy dużej liczbie zależności ma niebagatelne znaczenie. W długoterminowych projektach nie przeszkadza nam fakt, że na początku trzeba poświęcić trochę czasu na poskładanie do kupy struktury aplikacji oraz że spędzimy parę dni na tuningu wszystkich elementów. Właściwie to w dużych aplikacjach jest to rzecz, której wręcz oczekiwałbym od szanującego się programisty.
Zatem, dlaczego ZF-a porzuciłem? Odpowiedź jest prosta: stwierdziłem, że jednak MVP z pasywnym widokiem nie jest tym, czego mi potrzeba, a ponadto w paru miejscach liczba zależności dość mocno utrudniła mi zabudowanie jakiegoś autorskiego elementu tak, jak bym tego chciał. Ociężałość wielu komponentów oraz pojawienie się nowych technik projektowania w świecie PHP to ostatnie cegiełki do kompletu.
Podsumowanie
Moim zdaniem Zend Framework w ogólnym rozrachunku wypada jednak lepiej od Symfony. Dopiero po bliższym kontakcie z tym drugim naprawdę doceniłem jego przewidywalność, elastyczną strukturę i jakość dokumentacji. Fakt, docelowe zastosowanie jest nieco inne, ale może też właśnie dlatego wspominam go lepiej, jako że było ono bliższe temu, co sam tworzę. Warto także śledzić to, co dzieje się w sprawie Zend Frameworka 2.0, który - podobnie jak Symfony - jest przepisywany zgodnie z bardziej restrykcyjnymi zasadami projektowania i jakości kodu. Na pewno wyciągnięto tam wnioski z przynajmniej niektórych lekcji (normalne ładowanie klas), a co z tego wyjdzie, zobaczymy.
Jeśli zatem szukasz porządnego, elastycznego narzędzia do bardziej zaawansowanych projektów i nie przeraża Cię początkowy poziom trudności z połapaniem się w tym wszystkim, Zend Framework według mnie będzie dla Ciebie bardzo dobrym wyborem.
Napisał Sit w sobotę, 9 kwietnia 2011 o 16:50
A swoją drogą słyszeliście o doophp.com? Twierdzą że najszybszy framework w PHP. Zyx, może małe porównanie, benchmark i opis?