O frameworkach…

O php-owych frameworkach... słów kilka?
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, wiec nie siedzę na bieżąco w temacie php-owych frameworków.

Tak już jest, wole swoje kompilowane języki i desktopowe/systemowe aplikacje ;)
Na zaliczenie z projektu na uniwerku musze stworzyć panel do zarządzania serwerem usługowym. Jako serce zaprzęgłem Zend Framework.
Już kiedyś cos pisałem z "jego pomocą" i nawet przyjemnie się pisało, tylko ta ociężałość i rozbudowana struktura i funkcjonalność czasem może trochę sprawić problemów.

I tak sobie przeglądając dokumentacje tego frameworka wspomniałem sobie o moim projekcie małego, prostego i wydajnego frama, o którym pojawiły się kiedyś dwie notki: (pseudo)inteligentny router? i Fowardowanie akcji.

Naszła mnie chwila zastanowienia i przemyśleń, co z tym moim framem. W końcu kiedyś coś tam zacząłem pisać, na swoje potrzeby, aby spełniało moje wymagania i szybko ułatwiało pisanie czegokolwiek webowego.

Tak się zastanawiałem, 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 tego, co mi potrzeba. To czy warto jeszcze się babrać i coś swojego pisać, biorąc pod uwagę poświecony 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 (głównie przez skomplikowanie i elastyczność mająca na celu dopasowanie się do jak największej liczby możliwości i programistów z niego korzystających, tak żeby wszystkim dogodzić).

I może z tego powodu, warto cos sobie samemu napisać, tak aby mi się łatwo pisało i korzystało, bo 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.
Mi osobiście wydaje się bezużyteczny, bo ileż się namęczę, z jakimś trochę bardziej złożonym i skomplikowanym zapytaniem. Prędzej go napisze ręcznie, ba i szybsze to będzie, bo zanim ActiveRecords wygeneruje zapytanie, to minie trochę czasu. Tak, zgadza się ze to są mikrosekundy, i w ogóle nie zauważalne.
Ale dla mnie wygodniejsze jest napisanie zapytania, niż składanie go z 20 metod. Oczywiście przewagą ActiveRecorda jest miedzy innymi to, że 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ąś regule w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu, aby w efekcie otrzymać zamierzony cel działania ;)

W przytoczonych na początku notkach wspominających, co nieco o moim projekcie frameworka, opisałem tam pewien problem z nazewnictwem czy fowardowaniem akcji i kontrolerów o takiej samej nazwie, ale znajdujących się w logicznie innym poziomie (sub-folderze).
Wpadł mi do głowy taki pomysł, że realnie mogę olać foldery i trzymać wszystkie kontrolery w jednym, a strukturę pseudo-folderów będzie odwzorowana w nazwie danego pliku kontrolera, gdzie '_' będzie zastępował '/' z requesta. Powinno to rozwiązać zaistniałe problemy i nie trzeba byłoby przeszukiwać ciągle folderów z kontrolerami, choć ciągłego przeszukiwania można by uniknąć tworząc przy każdej zmianie struktury mapę odzwierciedlającą istniejącą strukturę kontrolerów.

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

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

Ale musze wybrać jakiegoś frama do kilku stron, które już dawno miały powstać, oczywiście mam na myśli polskie community wxWidgets oraz stronę projektu xime i związanych z nią serwisów, no i stronę domową, która chyba planowana jest już od lat. Pewnie albo Zend albo ten własny "frameworczek" zastosuje. Zobaczymy ;)

8 przemyśleń nt. „O frameworkach…”

  1. „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ś cos pisałem z “jego pomocą” i nawet przyjemnie się pisało, tylko ta ociężałość i rozbudowana struktura i funkcjonalność czasem może trochę sprawić 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ąś regule w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu, aby w efekcie otrzymać zamierzony cel działania ;)

    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 i 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 ;]

  2. Oczywiscie masz racje, dzieki za przydlugawego wpisu. Choc wiekszosc poruszanych tematow jest mi znana ;)

    O Kohanie slyszalem to i owo, ale jak wspomnialem webdeveloperka nie jest juz jednym z glownych moim zajec i co raz mniej mam z nia stycznosci.

    A projekt upadl bo nie bylo czasu, za duzo projektow rozpoczetych, za malo konczonych, ale obecnie najwazniejszy jest komunikator ;)

  3. 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 ;)

  4. Musialbym kiedys znalezc czas na zabranie sie za homepage’a, oraz udostenienie wszelakich projektow i infomacji o nich, bo troche kodu sie napsialo, a malo co jest dostepne ;)

    A VideoDownloaderowi przydalaby sie jakis update o nowa funckjonalnosc, no ale kazdy wie jak z czasem bywa :P

  5. 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.

  6. 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

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