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
| Temat | Zend Framework (PHP) | Django (Python) |
| Środowisko | PHP 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 |
| Konfiguracja | Ustawienia można zapisać w pliku INI, XML, Yaml albo bezpośrednio w kodzie | Django posiada po prostu plik settings, który może być dzielony na kawałki dla poszczególnych aplikacji |
| ORM | ZF 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 |
| Relacje | Samodzielne 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 |
| Rozszerzenia | ZF 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 panel | ZF 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.
About The Author
