O frameworkach PHP...

tech • 532 słowa • 3 minuty czytania

O php-owych frameworkach… słów kilka… a raczej o jednym, bądź dwóch, małe przemyślenia…

Może na początku powinienem podkreślić, że aktualnie webdeveloperką zajmuję się już bardzo sporadycznie, głównie na własne potrzeby, więc nie siedzę na bieżąco w temacie php-owych frameworków.

Tak już jest, że obecnie wolę swoje kompilowane języki i desktopowe/systemowe aplikacje ;)

Na uniwerku, na zaliczenie z projektu muszę stworzyć panel do zarządzania serwerem usługowym. Jako serce zaprzęgłem Zend Framework. Już kiedyś coś tworzyłem z “jego pomocą” i nawet przyjemnie się pisało, tylko ta ociężałość, rozbudowana struktura i funkcjonalność czasem może sprawić trochę problemów.

I tak sobie przeglądając dokumentację ZF-a przypomniałem sobie o moim projekcie małego, prostego i wydajnego frame-a, o którym pojawiły się kiedyś nawet dwie notki: Pseudo-inteligentny router w PHP i Forwardowanie akcji w PHP. Naszła mnie chwila zastanowienia… co z tym moim frameworkiem dalej? W końcu kiedyś coś tam już zacząłem pisać. Na swoje potrzeby, spełniające moje wymagania, aby ułatwiało mi pisanie czegokolwiek webowego.

I teraz tak się zastanawiam, czy to w ogóle ma sens, skoro jest Zend i multum innych, lepszych, bądź gorszych frameworków PHP. Skoro Zend ma wszystko, a nawet więcej, z tego co mi potrzeba, to czy warto jeszcze się babrać i coś swojego tworzyć, biorąc pod uwagę poświęcony na to czas, którego i tak nigdy nie ma?

To prawda, że czasem trzeba się trochę nagimnastykować w Zendzie czy innym, aby osiągnąć zamierzony cel. Co spowodowane jest głównie przez skomplikowanie i elastyczność mającą na celu dopasowanie się do jak największej liczby możliwości, przypadków użycia i programistów z niego korzystających. Tak żeby wszystkim dogodzić.

I może chociaż z tego powodu warto coś sobie napisać?
Coś co przede wszystkim mi ułatwi pisanie i korzystanie, bo w końcu inni mnie w tym wypadku już nie obchodzą ;)

Dochodzimy do tematu wygody i użyteczności.

Weźmy na przykład taki ActiveRecords i tym podobne wynalazki. W wielu przypadkach wydaje mi się bezużyteczny, bo ileż się namęczę z jakimś bardziej złożonym i skomplikowanym zapytaniem. Prędzej go napiszę “ręcznie”, co też będzie znacznie wygodniejsze, niż składanie go z 20 metod.

Oczywistą przewagą ActiveRecorda jest abstrakcja. Wystarczy zmienić implementację sterownika bazy i można generować zapytania do dowolnej bazy bez poprawiania kodu. Ale czy znów tak często zmieniamy bazę danych, szczególnie w nieco mniejszych aplikacjach?

Inna sprawa to porozrzucanie po 40 klasach 4 funkcji, i tworzenie 10 obiektów tylko po to, aby zmienić jakąś regułę w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu ;)

Tak sobie myślę, że chyba jednak dokończę tego mojego frameworka. Ileż to ja różnych projektów wstrzymałem, zawiesiłem, czy porzuciłem na różnych stopniach zaawansowania prac. Głównie z braku czasu oraz zmian w zapotrzebowaniu i użytkowaniu danego produktu (projektu). Wypadałoby chociaż cześć kiedyś skończyć bądź doprowadzić do jakiegoś stanu przydatności i używalności, bo może dla kogoś okażą się przydatne.

W sumie znam “trochę” Zenda i śp. CodeIgnitera, no i raczej nie planuję już nic poznawać w tej materii, bo po co? Jak napisałem na początku, webdeveloperką zajmuję się już bardzo rzadko, więc nie jest mi to potrzebne do życia jak kiedyś.

Niemniej, będę musiał wybrać jakiegoś frame-a do kilku stron, które dawno miały powstać. Pewnie będzie to albo Zend, albo ten mój własny “frame”. Zobaczymy ;)

Komentarze (8)

Nowaker
20080518-012433-nowaker

Ale czy znów tak często zmieniamy bazę danych, szczególnie w nieco mniejszych aplikacjach?

Często może i nie, co nie oznacza, że nie warto stosować warstwy abstrakcji na bazę danych. Za pół roku możesz np. zdecydować, że przenosisz swoje wszystkie projekty ze względów wydajnościowych z MySQL na PostgreSQL - i co wtedy zrobisz? Albo mozolnie zmienisz wszędzie mysql_ na odpowiedniki pg_ albo… olejesz sprawę, bo będzie z tym zbyt dużo roboty.

Już kiedyś coś tworzyłem z “jego pomocą” i nawet przyjemnie się pisało, tylko ta ociężałość, rozbudowana struktura i funkcjonalność czasem może sprawić trochę problemów.

Ja polecam frameworka KohanaPHP - mały i lekki framework, początkowo fork CodeIgnitera. Mi framework oferuje tyle, ile potrzeba. (Choć pewnie do ogromnych projektów się nie nada i takie Symfony okaże się lepsze)

Inna sprawa to porozrzucanie po 40 klasach 4 funkcji, i tworzenie 10 obiektów tylko po to, aby zmienić jakąś regułę w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu ;)

Wg mnie nie masz tutaj racji, ponieważ dokumentację bedziesz musiał tylko raz przejrzeć, aby skumać bazę [;)], ale później już nie będziesz tego odczuwał. Gdy zaś przyjdzie czas na jakąś przeróbkę w routingu, pójdzie ona gładko, podczas gdy w strukturalnym projekcie nie obeszło by się bez skakania po plikach i zmieniania wszystkie po kolei w wielu miejscach.

Głównie z braku czasu oraz zmian w zapotrzebowaniu i użytkowaniu danego produktu (projektu).

Hmmm, na moje to upadło w wyniku strukturalnego projektowania ;) Zmieniło się zapotrzebowanie i okazało się, że napisany strukturalnie system nie jest już przydatny.

Trochę się rozpisałem, wenę dziś załapałem ;]

Malcom
20080518-132952-malcom

Oczywiście masz rację, dzięki za przydługawy wpis. Choć większość poruszanych tematów jest mi znana ;)

O Kohanie słyszałem to i owo, ale jak wspomniałem webdeveloperka nie jest już jednym z głównych moim zajęć i coraz mniej już mam z nią styczność.

A projekt niestety upadł bo nie było czasu. Za dużo projektów rozpoczętych, za mało kończonych, ale obecnie najważniejszy jest komunikator ;)

Nowaker
20080518-182123-nowaker

Mały offtop: wszedłem sobie dzisiaj w Twoje portfolio i zobaczyłem VideoDownloader. Nieźle, mam ten widżet już dość długo, nawet nie wiedząc, że to Twoja robota ;)

Malcom
20080518-182744-malcom

Musiałbym kiedyś znaleźć czas na zabranie się za homepage’a, oraz udostepnienie wszelakich projektów i informacji o nich, bo trochę kodu się napisało, a mało co jest dostępne ;)

A VideoDownloaderowi przydałby się jakiś update o nową funkcjonalność, no ale każdy wie jak z czasem bywa :P

Nowaker
20080527-163454-nowaker

Czy mógłbym umieścić część Twojego wpisu u mnie na blogu wraz z moimi odpowiedziami? Bo w zasadzie rozpisałem się trochę i szkoda, by to uleciało ;) A wydaje mi się, że materiał jest ciekawy.

Malcom
20080527-221908-malcom

Oczywiście, że możesz… W sumie wystarczy “puścić” ping/trackbacka i stosowna adnotacja pojawi się przy tym wpisie ;)

20080528-225500-nowaker-net

[…] Malcom na swoim blogu podzielił się swoimi przemyśleniami na temat obiektowości w webdevelopingu, choć nie tylko. Jako że nie zgadzam się za bardzo, z tym, co napisał - odpisałem mu w komentarzu. Tak się tam rozpisałem, że zyskałem i materiał na wpis na moim blogu :) […]

Zyx
20080530-093122-zyx

Mnie we współczesnych frameworkach rozwala ich modularyzacja, która osiągnęła już chyba kres. Autorzy, gdyby mogli, umieszczaliby w osobnym pliku każdą instrukcję warunkową :). Oczywiście ma to swoje odbicie w wydajności, przynajmniej na mniejszych serwerach niewyposażonych w wiele “przyspieszaczy” w stylu ramdysków, akceleratorów i innych.

PS. Od baz danych obecnie jest PDO, a dodatkowa warstwa abstrakcji skupiająca całą obsługę baz danych w jednym miejscu (tak, że kontrolery itd. w ogóle nie muszą wiedzieć, że na jakiejś bazie siedzą) ma wiele zalet, głównie w kwestii wprowadzania poprawek i optymalizacji. Ostatnio przekonuję się powoli jednak do korzystania z gotowych systemów jej tworzenia (szczególnie PHP Doctrine), jako że ręczne pisanie wszystkich takich klas jest długawe i nużące. Ponadto np. PHP-Doctrine posiada wbudowaną implementację drzew na bazie danych, która w moim wykonaniu liczyła sobie prawie 60 kb kodu.

Dodaj komentarz

/dozwolony markdown/

/nie zostanie opublikowany/