Framework idealny – zmiana punktu widzenia

Odnoszę wrażenie, że moje przygody z PHP i próbą stworzenia przy użyciu tego języka porządnego frameworka są tylko kroplą w morzu prób innych osób starających się zrobić to samo. Dlaczego istnieje tak wiele i dużych zespołów i samodzielnych programistów, którzy podejmują się tego tematu i usiłują stworzyć na własną rękę coś co będzie wygodne dla nich i spełniało przy okazji swoją rolę. Wśród frameworków do PHP mamy dziesiątki „kobył” oraz setki mniejszych rozwiązań z czego przyjęły się głównie Zend Framework, Symfony, Yii, CodeIgniter i CakePHP. Przy czym każdy z nich mimo iż jest zupełnie inną implementacją to w zasadzie trzymają się one jednego i tego samego schematu. Ponadto wiele z nich posiada jakże ważne wzorce projektowe zaimplementowane we wzorowy sposób lecz co z tego skoro nie spełniają one swojego zadania w rzeczywistości a tych potrzebnych elementów do szybkiego tworzenia aplikacji jest jak na lekarstwo.

Nie chcę uchodzić za oświecanego fanboya frameworka Django do Pythona ale chciałbym przy jego pomocy porównać podejście do pracy i organizacji projektu oraz czasu, który się traci lub zyskuje z produktem flagowym do PHP czyli Zend Framework

TematZend Framework (PHP)Django (Python)
ŚrodowiskoPHP wymaga serwera WWW, żeby jakkolwiek sprawdzić efekty swojej pracy (w PHP 5.4 faktycznie dodano wbudowany serwer)Django udostępnia serwer developerski odrazu gotowy do pracy
KonfiguracjaUstawienia można zapisać w pliku INI, XML, Yaml albo bezpośrednio w kodzieDjango posiada po prostu plik settings, który może być dzielony na kawałki dla poszczególnych aplikacji
ORMZF w zasadzie nie posiada orma. Posiada on owrapowany metodami obiekt bazy danych składający wielkego selecta, który zwraca wynik zapytania.Django posiada przejrzysty orm ze składnią niezależną i nie sugerującą w ogóle używanie bazy danych
RelacjeSamodzielne relacje w zasadzie nie istnieją. Można je opisać w meta danych modelu jednak ich działanie nie spełnia oczekiwań, których możnabyłoby się spodziewać.Django w pełni opisuje modele na których pracuje dzięki czemu relacje między obiektami to żaden problem. Wystarczy odwołać się do dziecka czy rodzica po jego nazwie a Django samo wykona zapytanie i zwróci odpowiednio podzielony obiekt
RozszerzeniaZF wyposażony jest odrazu w szerego gotowych rozszerzeń jednak większości z nich nie uzywa się w każdym projekcie przez co zajmują niepotrzebnie miejsce i pamięć na serwerze.Django posiada niewiele rozszerzeń za to takich, które faktycznie się przydają praktycznie zawsze w prpfesjonalnym i kompletnym projekcie. Np generowanie sitemapy. Jeżeli jakaś funkcjonalność jest potrzebna na 99% jest gotowa i można ją dociągnać managerem pakietów
Admin panelZF nie posiada admin panelu – trzeba taką aplikację (nawet do celów wewnętrznych) napisać samemu.Django posiada Admin panel z pełnym CRUD’em i jest on na tyle praktyczny że jego konfiguracja może ograniczać się jedynie do podania odpowiednich parametrów w klasach (np szukarka ma szukać w tej i  tej kolumnie, na liście chcę wyświetlać te kolumny, a ta i ta ma być nieedytowalna. itd itd). Oczywiście można bez przeszkód dokonywać głębszych modyfikacji.

Starałem się przedstawić w/w porównanie w sposób uczciwy – na bazie swoich doświadczeń. Na pewno istnieje jeszcze wiele innych (może niekoniecznie mierzalnych) czynników, które wpływają w jakichś sposób na odbiór i przyjemność pracy – w moim przypadku własnie od tych niuansów zaczęła się fascynacja Django. Zobaczymy co przyniesie czas.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *