Frameworki PHP czyli CodeIgniter vs CakePHP

Początkowo byłem wielkim przeciwnikiem frameworków PHP – wydawał‚o mi się, że narzut i stopień skomplikowania, który w sobie mają zupełnie nie jest mi do szczęścia potrzebny. Pierwsze zetknięcie z Zend Framework było dla mnie dosyć traumatyczne. Rozmiar całej aplikacji przygniótł mnie na tyle, że dla większości moich zastosowań przewyższał on wielkość kodu podstawowego. Biorąc pod uwagę, że musiałem to wgrywać i aktualizować na wiele serwerów przyprawiał mnie o mdłości…

Niestety na tzw. “zachodzie” – chociaż nie wiem czy Australię można nazwać zachodem pracuje się lekko inaczej. Podstawą są tutaj gotowe rozwiązania zarówno w zakresie CMSów jak i w przypadku rozwiązań dedykowanych. Jeżeli chcesz dostać pracę MUSISZ znać co najmniej jeden framework MVC i jakiekolwiek środowisko z popularnych rozwiązań OpenSource.

Geneza

Nigdy nie byłem zwolennikiem w ułatwienia w postaci frameworków i gotowców. Wszystko w czystym PHP – działało ekstremalnie szybko i ekstremalnie niebezpiecznie. Potem złamałem się i zacząłem używać Smarty ‘ego i AdoDB . To było wszystko co potrzebowałem. Smarty rozwiązywał problem widoków, cache’owania szablonów i dogadywanie się z grafikami. AdoDB brało “na klatę” kwestię abstrakcji baz danych, cache’owania zapytań i wygody w wyciąganiu danych.

Niestety to za mało….

Zend Framework

Co za tym idzie musiałem się przełamać – próbowałem wrócić do Zenda – ale w tej kwestii nic się nie zmieniło. Za duży, za ciężki, za skomplikowany. Przejście przez tutorial zajmuje 2h, zbudowanie bazowej aplikacji 50 mb 😉

Pomijam oczywiście fakt, że do Zenda jest WSZYSTKO. Tak. Do wszystkiego są gotowe biblioteki. Czy to jest Amazon API, czy Google Storage czy coś jeszcze bardziej fikuśnego – dla Zenda naprawdę ktoś już to zrobił. Podobno nawet przy zastosowaniu Zend Optmizerów komercyjnych działa on bardzo szybko.

Moje próby z ZendServerem jakoś nie przekonały mnie do tego rozwiązania, wszystko chodziło nadal – dużo za wolno jak na moje wyszukane potrzeby i zboczenia optymlizatora.

CakePHP

Jakiś miły człowiek na swoim blogu napisał, że bardzo cieszy się, że nauczył się CakePHP – postanowiłem więc przyjrzeć się bliżej ciastku i… początkowo wydawało mi się to rozwiązanie całkiem sympatyczne. Faktycznie system jest RAPID. Robisz bazę, model, widok wio… samo działa. Zero zapytań do bazy, kodujemy tylko co trzeba poprzez rozbudowane tablice konfiguracji. Wszystko robi się samo… no właśnie.

Co mi się nie spodobało od razu to rozdrobnienie widoków – koszmarne rozdrobnienie, oczami widzę łączenie i otwieranie 50 plików dla jednego projektu. W sumie fajnie, wszystko osobno, można dopieścić, dograć… ale… no za dużo. Za dużo katalogów, za dużo plików – no i niestandardowe rozszerzenia .ctp ? co to kurde jest…

Wprawdzie powala liczba dodatkowych bibliotek i rozszerzeń, ale słaba dokumentacja i kompletna niekompatybilność wersji powodują, że system ten moim skromnym zdaniem się nie nadaje.

Gwoździem do trumny okazał się fakt, że projekt który wykonuję zawodowo został właśnie napisany w tym “rapid” systemie. Projekt jest duży – bardzo duży. Pomijam fakt totalnego spieprzenia kodu przez programistów, ale skoro aplikacja zdycha przy 100 użytkownikach na raz… przyszło mi zdiagnozować tenże kod głębiej za pomocą profilera.

Okazało się, że kod nie jest mocno spieprzony. To narzut naszego ukochanego CakePHP robi swoje. Tworzenie samych modeli i podstawowych zapytań to raptem 250 odwołań do konstruktura modelu, co daje wykonania poszczególnych operacji na poziomie 1000 iteracji!!! Gdzie tak naprawdę w “czystym PHP” dana operacja łącznie z mocną validacją kodu i zapytaniami do bazy daje nam naprawdę kod nieprzekraczający 50 kb 🙂 mój bazowy kontroler liczy sobie 550 kb – a to tylko definicje – zero kodu faktycznego.

Co jeszcze… ogromne problemy z dziedziczeniem – niby wystarczy dodać deklarację na początku kontrolera czy klasy i samo się “ładuje” ale to nie jest prawdą 🙂 Szczególnie jak korzystamy z App::import które jest nieuniknone. Ręczne ładowanie modelu też nie zawsze działa – zależy skąd wywołamy funkcję.

Rozbicie kontrolera na komponenty, widoków na elementy, layoty i co tam jeszcze sobie chcecie – po co? Więcej includów, więcej syfu do ogarnięcia.

Jednym słowem – trzymajcie się od tego z daleka. Tak – jest rapid, ma mnóstwo bibliotek, ale ten kod się nie nadaje do niczego!!!

CodeIgniter

Framework w sumie bardzo prosty. Wszystko jest w nim proste. Model nic za nas nie robi, widoki trzeba ładować “po nazwie”. Kontroler trzeba napisać samemu. Co więc w nim fajnego? Właśnie ta prostota. Mamy piękne MVC – czyli separujemy wygląd strony od kontrolera wydarzeń i samych modeli na których operujemy. Do tego dostajemy wszystko co jest potrzebne – abstrakcję baz danych, widoki pięknie dziedziczą co trzeba – a w zasadzie to czym je nakarmimy, a w kontrolerach można ładować co się chce i kiedy się chce.

Rozwiązane są też odwieczne problemy z cachowaniem (baz danych i widoków), ogólnym cachowaniem (mamcached, APC, czy co tam sobie chcesz). Jest sporo bibliotek które załatwiają podstawowe potrzeby, sporo helperów które robią resztę a wszystko za cenę minimalnego narzutu ze strony frameworka.

Zapytania do bazy można pisać “z ręki” czyli standardowo “SELECT id, name FROM” albo skorzystać z Active Record Class , która zrobi to za nas. Zapytania można cache’ować, wyniki wyciągać w postaci obiektów lub tablic. Polecam na zajrzenie do dokumentacji , która naprawdę jest fantastyczna – w bardzo prosty sposób tłumaczy wszystko co trzeba bez zbędnego wchodzenia w detale.

Wszystko jest przejrzyste i baaardzo wydajne. Praktycznie “nie czuje” się, ze pracujesz we frameworku i coś w tle spowalania nasz projekt.

Rozszerzenie o dodatkowe biblioteki czy moduły jest proste, projekt ten rozwija się naprawdę dynamicznie i życze mu wszystkiego najlepszego. Jeżeli chcesz zacząć swoją przygodę z MVC – zacznij od CodeIgnitera. Potem możesz pomyśleć o czymś innym.

A… żeby nie było. To nie jest żart mimo tej charakterystycznej daty.

Dzisiejszy przydługi wpis sponsoruje Hankey Bannister 😉