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.

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

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

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