Wybór Frameworka. Opcje

[Lk_hc]

Witam, jestem początkującym, raczej mało znającym inżynierie oprogramowania, koderem. Ostatnimi czasy zagłębiam się w temat Frameworków. Chciałbym abyście poradzili mi jakiego Frameworka wybrać do nauki i wydajnego tworzenia aplikacji z naciskiem na naukę. Chciałbym środowiska które nie robi wszystkiego za mnie, daje dużo wolnej ręki a jednocześnie jest przejrzyste. Zależałoby mi na tym aby było do niego dostępnych trochę polskich tutoriali (niekoniecznie polska dokumentacja ale byłoby super).

Przyglądałem się już ZF ( heavymind ) oraz phiendowi i artom na jego temat na php.pl, wydaje mi się że oba w pewnym stopniu mi nie pasują, cakePhp wydaje się mało rozbudowany. Co możecie poradzić?

Powód edycji: [Spawnm]: przenoszę do działu 'Frameworki' oraz przypinam.

[phpion]

@athlabus:
Fakt, stworzyć aplikację na pewno można szybciej przy pomocy Symfony (generator modeli, generator admina etc.). Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza. Co tam jeszcze... konfiguracja w *.yml. No dobra, fajnie, ale często miałem problem typu "!@#$% jak to zapisać w YML?". M.in. z tych właśnie powodów odszedłem od Symfony - za dużo kombinowania jak dla mnie.
Jeżeli dobrze Ci się kodowało w CI to zapewniam Cię, że w K będzie Ci się kodowało jeszcze przyjemniej. Wybór jednak należy do Ciebie, my możemy jedynie wyrazić nasze prywatne zdanie.

[michalg]

@athlabus:
Problemy jednak zaczynają się w momencie gdy trzeba coś zmienić (np. dodać nowe pole do tabeli, które dodatkowo będzie w relacji z inną tabelą) lub zmienić wygląd admina. Wszystko jest oczywiście możliwe, tego nie neguję, jednak dla mnie było to bardzo upierdliwe. Może źle szukałem ale nie znalazłem w Internecie informacji w jaki sposób korzystać z widoków PostgreSQL. Nie podoba mi się również to, że pola w tabeli w bazie danych są uniwersalne tj. takie, które są poprawnie interpretowane w najpopularniejszych silnikach baz danych (ale to już nie wina Symfony tylko samego Propela). Pisząc system pod PostgreSQL chcę w pełni wykorzystyać listę typów danych, jakie oferuje ta baza.

No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.

Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM.

[phpion]

No niestety, taka jest cena abstrakcji bazy danych. Ale przecież nie musisz korzystać z propela przy pisaniu projektu pod symfony - zawsze możesz korzystać bezpośrednio z sqli.

No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela?

Jeżeli chodzi o możliwość wykorzystania dodatkowych typów z psql przy użyciu ORM, to *teoretycznie* mógłbyś tworzyć strukturę bazy za pomocą ręcznie pisanego DDLa zamiast generowanego przez ORM.

No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem.

[michalg]

No coś Ty. W Kohana również mam abstrację bazy danych i nie mam żadnych wyżej opisanych problemów. Korzystanie bezpośrednio z raw SQL? W takim razie po co mi "dobrodziejstwa" Propela?


No tak, tylko znowu jesteśmy w punkcie opisanym powyżej: po co nam w takim wypadku cały Propel? W tym momencie staje się on przeszkodą niż ułatwieniem.

To jak to wygląda w Kohana? Możesz to pokrótce opisać, bo szczerze mówiąc nie znam tego, a jestem ciekaw. Chodzi mi o etap przygotowania schematu bazy danych oraz dostępu. I czy w Kohanie masz abstrakcję na obu tych etapach?