Temat: Fromewroki a ciężka praca

Proponuję spojrzeć na problem wykorzystania gotowych rozwiązań od strony zlecającego - jeśli na zbudowanie nowej funkcjonalności potrzebuję 2 tygodni pisząc wszystko od zera, a wykorzystując gotowe rozwiązania uwinę się w 2 dni, to odpowiedź jest prosta - chcę wykorzystać gotowe elementy, bo: zaoszczędzę kasę, mogę otrzymać następną funkcjonalność. Co równie ważne łatwiej znajdę nowego programistę, szybciej wprowadzę go do projektu - będzie się mógł skupić na realizowaniu potrzeb klienta, łatwiej też wprowadzać modyfikacje do kodu, pod warunkiem przestrzegania standardów kodowania, o których wspomniano wcześniej.

Temat: Fromewroki a ciężka praca

Każdy framework w jakimś stopniu jest subiektywnym punktem widzenia jego twórców. Praktycznie każdy w pewnym momencie dokonuje dość daleko idących zwrotów wcześniejszych założeń. To nie assembler dla danej grupy układów, gdzie przez kilka lat baza potrafi być niezmienna. W PHP nagłe zwroty często prowadzą albo do rozłamu projektu na równolegle idące gałęzie (np. Kohana), albo do porzucenia dotychczasowej metodyki, co z kolei generuje problem migracji rozwijanych projektów na nową, zwykle niekompatybilną wersję (patrz: Zend Framework v1 vs v2). W związku z powyższym nauka frameworków w rozumieniu zdobywania wiedzy jest średnim pomysłem. Jest wiele równorzędnych narzędzi, a wybór powinien zależeć od określonych czynników środowiskowych - nie od tego, co akurat poznaliśmy. Jak ktoś zaciąga kobyłę typu ZF1 do pisania prostego API czy też stawia sklepik z komórkami w oparciu o Magento, to zwyczajnie nie zrozumiał na czym polega koncepcja takich narzędzi.

Jeśli komuś zależy na maksymalnym otworzeniu umysłu na zasady działania frameworków, to powinien zainteresować się ogólną metodyką wzorca MVC, zwłaszcza w kwestii rozdzielenia warstw modelu i kontrolera, a także dopuszczalnej ingerencji logiki w warstwę widoku (pomijając już fakt, że klasyczny MVC w zasadzie nie istnieje). Fajnym wstępem może być książka "Wzorze MVC w PHP dla profesjonalistów". Tytuł może głupawy, ale autor faktycznie przechodzi z czytelnikiem przez cały proces budowania własnego frameworka, jednocześnie opierając się na sprawdzonych paradygmatach. Analiza frameworków od środka wyjaśnia sens ich istnienia - kolejne przypadki, gdzie z pozoru skomplikowane zadanie wykonujemy w znacznie krótszym czasie niż wskazuje nam nasza intuicja powodują, że w pewnym momencie przestawia się nam dotychczasowy sposób myślenia o programowaniu w PHP. Pytanie, czy dana osoba poradzi sobie z pełnym zrozumieniem tej pozycji. Jeśli nie - cóż, na początek można pobawić się wykorzystując któryś z możliwie prostych frameworków - Yii, Kohana 2.3, CakePHP. Zendów czy Symfony na początek zdecydowanie nie polecam - sam tak zaczynałem i dopiero po dłuższym (czytaj: zdecydowanie za długim) czasie zrozumiałem większość bazowych mechanizmów tego systemiku.

Temat: Fromewroki a ciężka praca

Radosław S.:
Każdy framework w jakimś stopniu jest subiektywnym punktem widzenia jego twórców. Praktycznie każdy w pewnym momencie dokonuje dość daleko idących zwrotów wcześniejszych założeń. To nie assembler dla danej grupy układów, gdzie przez kilka lat baza potrafi być niezmienna. W PHP nagłe zwroty często prowadzą albo do rozłamu projektu na równolegle idące gałęzie (np. Kohana), albo do porzucenia dotychczasowej metodyki, co z kolei generuje problem migracji rozwijanych projektów na nową, zwykle niekompatybilną wersję (patrz: Zend Framework v1 vs v2). W związku z powyższym nauka frameworków w rozumieniu zdobywania wiedzy jest średnim pomysłem. Jest wiele równorzędnych narzędzi, a wybór powinien zależeć od określonych czynników środowiskowych - nie od tego, co akurat poznaliśmy. Jak ktoś zaciąga kobyłę typu ZF1 do pisania prostego API czy też stawia sklepik z komórkami w oparciu o Magento, to zwyczajnie nie zrozumiał na czym polega koncepcja takich narzędzi.

No nie do końca. Bo to "zwykłe API" potrzebuje:
- routingu
- orm / odm lub coś od innego źródła danych
- obsługi błędów
- logowanie zdarzeń
- jakiś kontroler
- obsługę różnych metod (GET, POST, PUT, DELETE itp itd etc)
- może jakąś autoryzację
- i kontrolę dostępu
- i paru innych rzeczy
i nagle się okaże że ZF czy S2 to dokładnie to co Ci potrzeba do tego "zwykłego API". Ewentualnie zawsze możesz sięgnąć po jakiś micro-framework.

Jeśli komuś zależy na maksymalnym otworzeniu umysłu na zasady działania frameworków, to powinien zainteresować się ogólną metodyką wzorca MVC, zwłaszcza w kwestii rozdzielenia warstw modelu i kontrolera, a także dopuszczalnej ingerencji logiki w warstwę widoku (pomijając już fakt, że klasyczny MVC w zasadzie nie istnieje). Fajnym wstępem może być książka "Wzorze MVC w PHP dla profesjonalistów". Tytuł może głupawy, ale autor faktycznie przechodzi z czytelnikiem przez cały proces budowania własnego frameworka, jednocześnie opierając się na sprawdzonych paradygmatach. Analiza frameworków od środka wyjaśnia sens ich istnienia - kolejne przypadki, gdzie z pozoru skomplikowane zadanie wykonujemy w znacznie krótszym czasie niż wskazuje nam nasza intuicja powodują, że w pewnym momencie przestawia się nam dotychczasowy sposób myślenia o programowaniu w PHP. Pytanie, czy dana osoba poradzi sobie z pełnym zrozumieniem tej pozycji. Jeśli nie - cóż, na początek można pobawić się wykorzystując któryś z możliwie prostych frameworków - Yii, Kohana 2.3, CakePHP. Zendów czy Symfony na początek zdecydowanie nie polecam - sam tak zaczynałem i dopiero po dłuższym (czytaj: zdecydowanie za długim) czasie zrozumiałem większość bazowych mechanizmów tego systemiku.

Jednak w którymś momencie uderzamy w moment kiedy framework staje się podstawą dla nas. Z prostej przyczyny. Jak lubujemy się we wzorcach i implementujemy je robiąc kolejne narzędzia - okazuje się że jak przychodzi nowy programista do zespołu czy kogoś zatrudniamy - ten ktoś musi się wdrażać w tonę nowych rzeczy. A im dłużej rozwijamy projekt tym gorzej dla niego.

W momencie jak korzystasz z ZF czy Symfony, sprawa jest prosta. Ogarniasz samą aplikację bo narzędzia już znasz.

Więc na dłuższą metę framework zawsze będzie tańszy i szybszy. Kwestia jakie wybrać. Ja np nie uczyłem się nie wiadomo ilu. Liznąłem ZF i sporo pracuje z Symfony 2. Tak samo z front-endowymi. Nie zagłębiałem się w Backbone itp itd etc. Wskoczyłem na todomvc, zrobiłem review implementacji aplikacji "todo" i wybrałem Angulara bo wydaje mi się najlepszy. Później jeszcze przekopałem się przez opinie i i blogi żeby się upewnić że żaden kamień nie zostanie powieszony u mojej nogi.

Tak było np z Express.js. Micro-framework dla Node.js. Fajny, lekki szybki ale ubogi jak diabli. I tak jak zacząłem go bootstrapować to został z niego sam middleware czyli connect. Ale akurat żadna dziwota bo Node.js jest młody i dobre narzędzia dopiero na niego powstają.

Nie zgodzę się też z Twoim pośrednim (tak to odebrałem) stwierdzeniem że narzędzia trzeba rozumieć by je używać. Narzędzia trzeba znać. Możesz pracować cepem bez poznania jego budowy. Wystarczy znać zalecenia i ogólny zamysł. Jednak oczywiście zawsze pożądane jest by międzyczasie budowę cepa poznać jeżeli będziemy chcieli z nim robić jakieś zaawansowane rzeczy.Ten post został edytowany przez Autora dnia 17.03.14 o godzinie 22:23

Temat: Fromewroki a ciężka praca

@Dariusz Półtorak

Nie napisałem, że frameworki są zbyteczne. W firmach, w których pracowałem zawsze dążyłem do ujednolicenia stosowanych technologii. Można nawet powiedzieć, że jestem przeciwnikiem koncepcji "daj, sam zrobię to lepiej", bo przez takie myślenie zdycha większość fajnych projektów (nie tylko librarki do PHP, ale np. udane dystrybucje linuksowe pokroju KateOS).

W swojej wypowiedzi użyłeś ważnego słowa, słowa klucza - "używać". Frameworków się nie uczymy, frameworków używamy. Przyjmujemy ich koncepcje jakie w danej chwili obowiązują i piszemy. Z kolei zrozumienie zasad ich działania jest niezmiernie ważne. Bez tego przykładowo nie da rady napisać w miarę szybkiej apki w oparciu o ZF1. Pierwsze zderzenie wleci już w momencie nagminnego stosowania plików INI, do czego zachęca manual i można rzec - społeczność. Oczywiście to tylko przykład. Napisałem z 10 jakiś małych apek zanim zacząłem faktycznie rozumieć jak zbudowany jest ZF1. Wiem, że za długo mi to zajęło, ale ZF1 był pierwszym frameworkiem mvc z jakim miałem do czynienia po dłuższej przerwie w zawodzie (wcześniej PHP4 strukturalny).

Pisząc o prostym API chodziło mi o fakt, że tutaj w grę wchodzi głównie wydajność. ORM, AR w ogóle według mnie odpadają. Routing oczywiście i to jak najprostszy. Zresztą właśnie przymierzam się do takowego zadania i jak na razie wygrywa Phalcon. ZF czy Symfony są zbyt zasobożerne (co nie oznacza, że do klasycznych apek średniego obciążenia nie wybieram zenda).

Ktoś tutaj wspomniał o czasie wykonania zadania (czytaj: zlecenia) jako wyznacznika, czy narzędzia warto używać. Cóż, jeśli rozumieć to dosłownie - przykre, po prostu przykre. Gdzieś zatracił się programistyczny zmysł, aby kodować w sposób optymalny wydajnościowo. Rozumiem, że AR i podobne bajery kuszą, ale należy się zawsze zastanowić, czy wolno tego użyć. Większość frameworków cierpi właśnie z powodu podejścia "zautomatyzuj wszystko, co się da". Aby uczynić je w miarę wydajnymi trzeba pokombinować, trzymając zapał na wodzy, i racjonalnie przeanalizować co dane rozwiązanie może spaprać. Nie można przyjąć beztrosko, że backend, to backend, więc liczy się jedynie czas wykonania "bo i tak będzie korzystała z tego jedna-dwie osoby jednocześnie". Pozostaje mieć nadzieję, że programiści PHP nadal wyborów dokonują świadomie.

Temat: Fromewroki a ciężka praca

Radosław S.:
@Dariusz Półtorak

Nie napisałem, że frameworki są zbyteczne. W firmach, w których pracowałem zawsze dążyłem do ujednolicenia stosowanych technologii. Można nawet powiedzieć, że jestem przeciwnikiem koncepcji "daj, sam zrobię to lepiej", bo przez takie myślenie zdycha większość fajnych projektów (nie tylko librarki do PHP, ale np. udane dystrybucje linuksowe pokroju KateOS).

W swojej wypowiedzi użyłeś ważnego słowa, słowa klucza - "używać". Frameworków się nie uczymy, frameworków używamy. Przyjmujemy ich koncepcje jakie w danej chwili obowiązują i piszemy.

Nie no, dlaczego się nie uczyć? Każdy framework ma swoje niuanse a profesjonalizm to też właśnie dbałość o szczegóły. Osobiście uważam, że znajomość narzędzi (w tym frameworków) i umiejętność zwinnego / efektywnego korzystania z nich w dzisiejszych czasach to mega duży plus na rynku pracy i jest to cenione powyżej znajomości samego danego języka programowania.

Z kolei zrozumienie zasad ich działania jest niezmiernie ważne. Bez tego przykładowo nie da rady napisać w miarę szybkiej apki w oparciu o ZF1. Pierwsze zderzenie wleci już w momencie nagminnego stosowania plików INI, do czego zachęca manual i można rzec - społeczność. Oczywiście to tylko przykład. Napisałem z 10 jakiś małych apek zanim zacząłem faktycznie rozumieć jak zbudowany jest ZF1. Wiem, że za długo mi to zajęło, ale ZF1 był pierwszym frameworkiem mvc z jakim miałem do czynienia po dłuższej przerwie w zawodzie (wcześniej PHP4 strukturalny).

Zrozumienie zasad działania a wnikanie w kod to dwie różne rzeczy. Nie przesadzajmy też z mityczną powolnością frameworków :-) Np. problem konfiguracji można rozwiązać tak samo jak jest on rozwiązany w sf - cachowaniem konfiguracji. Kwestia odopwiedniego podejścia. Poza tym patrząc z punktu widzenia klienta: co mi po tym że będę potrzebował jeden serwer aplikacji mniej jak żeby cokolwiek zmienić w niej płacić krocie i czekać niewiadomo jak długo bo jest ciężka w zarządzaniu.... i tu chyba pojawia się następny aspekt... nie można tylko profilować prostego przypadku "hello world" i stawiać wynik za priorytet (wdług mnie), bo to sytuacja odrealniona.

Pisząc o prostym API chodziło mi o fakt, że tutaj w grę wchodzi głównie wydajność. ORM, AR w ogóle według mnie odpadają. Routing oczywiście i to jak najprostszy. Zresztą właśnie przymierzam się do takowego zadania i jak na razie wygrywa Phalcon. ZF czy Symfony są zbyt zasobożerne (co nie oznacza, że do klasycznych apek średniego obciążenia nie wybieram zenda).

Trzeba pamiętać że overoptimizing i overscalling to wcale nic dobrego, a nawet często powód totalnego uwalenia projeku...

Ktoś tutaj wspomniał o czasie wykonania zadania (czytaj: zlecenia) jako wyznacznika, czy narzędzia warto używać. Cóż, jeśli rozumieć to dosłownie - przykre, po prostu przykre. Gdzieś zatracił się programistyczny zmysł, aby kodować w sposób optymalny wydajnościowo. Rozumiem, że AR i podobne bajery kuszą, ale należy się zawsze zastanowić, czy wolno tego użyć. Większość frameworków cierpi właśnie z powodu podejścia "zautomatyzuj wszystko, co się da". Aby uczynić je w miarę wydajnymi trzeba pokombinować, trzymając zapał na wodzy, i racjonalnie przeanalizować co dane rozwiązanie może spaprać. Nie można przyjąć beztrosko, że backend, to backend, więc liczy się jedynie czas wykonania "bo i tak będzie korzystała z tego jedna-dwie osoby jednocześnie". Pozostaje mieć nadzieję, że programiści PHP nadal wyborów dokonują świadomie.

Cóż, świat się zmienia i trzeba się przystosować do nowych realiów. Teraz inaczej się koduje, inne są priorytety inny też jest cykl życia aplikacji i dewelopmentu. Dla mnie to ogromny plus, że zasoby ludzkie są bardziej cenione niż praca maszyn.

Temat: Fromewroki a ciężka praca

Piotr L.:
Zrozumienie zasad działania a wnikanie w kod to dwie różne rzeczy. Nie przesadzajmy też z mityczną powolnością frameworków :-) Np. problem konfiguracji można rozwiązać tak samo jak jest on rozwiązany w sf - cachowaniem konfiguracji. Kwestia odopwiedniego podejścia. Poza tym patrząc z punktu widzenia klienta: co mi po tym że będę potrzebował jeden serwer aplikacji mniej jak żeby cokolwiek zmienić w niej płacić krocie i czekać niewiadomo jak długo bo jest ciężka w zarządzaniu.... i tu chyba pojawia się następny aspekt... nie można tylko profilować prostego przypadku "hello world" i stawiać wynik za priorytet (wdług mnie), bo to sytuacja odrealniona.

Dobrze powiedziane. Dlatego ja osobiście, wszelkie porównania frameworków po prostu ignoruję. Dlaczego? Bo jeszcze chyba nie spotkałem się z sytuacją, w której porównywana byłaby konkretna aplikacja. Nie "Hello world", nie zwykły CRUD (dwie, trzy operacja na krzyż), ale konkretna aplikacja, napisana w porównywanych frameworkach. Wtedy ma to jakieś znaczenie. Tylko...

Tylko, że tak naprawdę to całe porównywanie nie ma sensu i odbywa się na zasadzie wyższości jednych świąt nad drugimi. Jednym z powodów, dla których używamy frameworków jest przyspieszenie procesu tworzenia oprogramowania. A to, w czym się to osiągnie, ma raczej znaczenie marginalne.

Choose the right tool for the job - to jest zasada, o której świadomość powinien mieć każdy programista.

Trzeba pamiętać że overoptimizing i overscalling to wcale nic dobrego, a nawet często powód totalnego uwalenia projeku...

Premature optimization is a root of all evil ;-)

Radosław S.:
W swojej wypowiedzi użyłeś ważnego słowa, słowa klucza - "używać". Frameworków się nie uczymy, frameworków używamy. Przyjmujemy ich koncepcje jakie w danej chwili obowiązują i piszemy. Z kolei zrozumienie zasad ich działania jest niezmiernie ważne. Bez tego przykładowo nie da rady napisać w miarę szybkiej apki w oparciu o ZF1. Pierwsze zderzenie wleci już w momencie nagminnego stosowania plików INI, do czego zachęca manual i można rzec - społeczność. Oczywiście to tylko przykład. Napisałem z 10 jakiś małych apek zanim zacząłem faktycznie rozumieć jak zbudowany jest ZF1. Wiem, że za długo mi to zajęło, ale ZF1 był pierwszym frameworkiem mvc z jakim miałem do czynienia po dłuższej przerwie w zawodzie (wcześniej PHP4 strukturalny).

Frameworka jak najbardziej się uczymy.

Temat: Fromewroki a ciężka praca

Może jestem dinozaurem, ale jeśli teraz branżą rządzi zasada "byle szybciej, byle więcej", to zaczynam rozumieć dlaczego niemal każda apka sieciowa z jaką ostatnimi czasy się stykam naszpikowana jest błędami. Żeby to jeszcze były jakieś twory domorosłych koderów, ale projekty typu Orange-Online, Allegro, Agito czy Google Play, to jednak zupełnie inny pułap wymaganych umiejętności.

Powolność większości frameworków spowodowana jest sporą warstwą abstrakcji. Odpytywanie o schemat bazy, API Reflection, generowanie obiektów w oparciu o pseudo PHPdoc, domyślne ładowanie pełnego zestawu librarek. Bez zrozumienia jak to wewnątrz działa nie da się realnie oszacować czy dany nadmiarowy nakład mocy obliczeniowej można zaakceptować. Jak już @Andrzej Ośmiałowski wspomniał "Hello World" nie jest żadnym wyznacznikiem i bez realnej analizy działania dwóch aplikacji z identyczną funkcjonalnością nie stwierdzimy, czy "jest dobrze".

Tak przy okazji - wszelkich miłośników ORMów i AR zachęcam do porównania jak dana funkcjonalność wypada przy zastosowaniu bezpośredniego DAO. Na czymkolwiek co wykonuje chociaż 3-4 operacje na bazie.

Kiedyś miałem ciągoty do nauki wszelakich technologii. Dosłownie co pod rękę wpadło. W pewnym momencie zrozumiałem, że narzędzia rozwijają się zbyt szybko, aby ciągle być ze wszystkim na bieżąco. Dobrze wykształcona "intuicja" pozwala szybko usiąść do zupełnie nowego kawałka kodu bez konieczności systematycznego wkuwania krok po kroku koncepcji narzędzia. Odcięcie się od narzędzi na rzecz koncepcji ma jeszcze jedną zaletę - siadając do czegoś nowego nie zmagamy się z podświadomie wyuczonym sposobem myślenia.

Temat: Fromewroki a ciężka praca

zgadzam się z przedmówcami, jednakże rynek w moim odczuciu wymusza pewne chińskie tryby pracy u programistów, dla których niestety atrybut w postaci czasu jest kluczowy i priorytetowy - inne elementy odchodzą na dalszy plan.
Widać to chociażby po komentarzach jakie pojawiły się przy książce do Yii jednego z większych wydawnictw. Full opinii jakie się pojawiły krytykowały autora iż nie umówił query buildera tylko klepał regularne zapytania do bazy (defakto autor na koniec wyjaśnia dlaczego)

podsumuję krótko - takie czasy

Temat: Fromewroki a ciężka praca

Paweł L.:
zgadzam się z przedmówcami, jednakże rynek w moim odczuciu wymusza pewne chińskie tryby pracy u programistów, dla których niestety atrybut w postaci czasu jest kluczowy i priorytetowy - inne elementy odchodzą na dalszy plan.
Widać to chociażby po komentarzach jakie pojawiły się przy książce do Yii jednego z większych wydawnictw. Full opinii jakie się pojawiły krytykowały autora iż nie umówił query buildera tylko klepał regularne zapytania do bazy (defakto autor na koniec wyjaśnia dlaczego)

podsumuję krótko - takie czasy

Jeśli wspominasz o książce Yii autorstwa Łukasza Sosny, to jest ona idealnym przykładem jak nie należy pisać książek. Miałem nieprzyjemność to przeczytać. Na każdym kroku ma się wrażenie, że człowiek ten w ogóle nie ma pojęcia o pracy z php & wzorzec mvc. Opis to próba wywnioskowania z kodu (a raczej nazw metod i obiektów) co tak naprawdę się dzieje. Gdy wpada jakiś fragment wymagający omówienia przekazywanych parametrów strzela lakoniczne zdanie będące tak naprawdę odczytaniem nazw tychże parametrów. Czarę przelało perfidne wodolejstwo, a chyba nawet trafniej będzie określić to mianem próby zwiększenia objętości książki. Pomijając już nawet fragment o wbudowanych walidatorach, gdzie za każdym razem od nowa budowany był ten sam fragment kodu, to moment, w którym dostajemy na twarz kilka stron z kodem "lorem ipsum" wrzucanym do bazy najzwyczajniej mnie dobił. Jest to zdecydowanie najgorsza książka, jaką miałem w rękach (a przeczytałem ich całkiem "sporo").

Co do "query builderów" - nie są takie złe. Powiedziałbym, że mamy tutaj taki racjonalny kompromis między magicznymi metodami ORMów odwołujących się beztrosko do schematu bazy, a topornymi zapytaniami SQL wstrzykniętymi perfidnie w kod. Mówię tutaj o takiej koncepcji jaką można spotkać w ZF1. Może i mamy nadmiarowe odwołania do funkcji, ale owe funkcje jednocześnie odpowiadają za sprawną konkatenację fragmentów zapytania oraz ochronę przed SQL Injection.

Temat: Fromewroki a ciężka praca

Radosław S.:

Paweł L.:
zgadzam się z przedmówcami, jednakże rynek w moim odczuciu wymusza pewne chińskie tryby pracy u programistów, dla których niestety atrybut w postaci czasu jest kluczowy i priorytetowy - inne elementy odchodzą na dalszy plan.
Widać to chociażby po komentarzach jakie pojawiły się przy książce do Yii jednego z większych wydawnictw. Full opinii jakie się pojawiły krytykowały autora iż nie umówił query buildera tylko klepał regularne zapytania do bazy (defakto autor na koniec wyjaśnia dlaczego)

podsumuję krótko - takie czasy

Jeśli wspominasz o książce Yii autorstwa Łukasza Sosny, to jest ona idealnym przykładem jak nie należy pisać książek. Miałem nieprzyjemność to przeczytać. Na każdym kroku ma się wrażenie, że człowiek ten w ogóle nie ma pojęcia o pracy z php & wzorzec mvc. Opis to próba wywnioskowania z kodu (a raczej nazw metod i obiektów) co tak naprawdę się dzieje. Gdy wpada jakiś fragment wymagający omówienia przekazywanych parametrów strzela lakoniczne zdanie będące tak naprawdę odczytaniem nazw tychże parametrów. Czarę przelało perfidne wodolejstwo, a chyba nawet trafniej będzie określić to mianem próby zwiększenia objętości książki. Pomijając już nawet fragment o wbudowanych walidatorach, gdzie za każdym razem od nowa budowany był ten sam fragment kodu, to moment, w którym dostajemy na twarz kilka stron z kodem "lorem ipsum" wrzucanym do bazy najzwyczajniej mnie dobił. Jest to zdecydowanie najgorsza książka, jaką miałem w rękach (a przeczytałem ich całkiem "sporo").

zgadzam się - defakto w moim poście nie oceniałem książki , która jest faktycznie słaba a lorem ipsum na kilka stron rozkłada na łopatki, a jedynie pewien schemat myślenia

Co do "query builderów" - nie są takie złe. Powiedziałbym, że mamy tutaj taki racjonalny kompromis między magicznymi metodami ORMów odwołujących się beztrosko do schematu bazy, a topornymi zapytaniami SQL wstrzykniętymi perfidnie w kod. Mówię tutaj o takiej koncepcji jaką można spotkać w ZF1. Może i mamy nadmiarowe odwołania do funkcji, ale owe funkcje jednocześnie odpowiadają za sprawną konkatenację fragmentów zapytania oraz ochronę przed SQL Injection.

co do query builderow - zwracają o kilka zapytań wiecej do bazy niz standardowe zapytanie - defakto spowalniając działanie apki i ta teza jest bezsporna

Temat: Fromewroki a ciężka praca

Paweł L.:

Co do "query builderów" - nie są takie złe. Powiedziałbym, że mamy tutaj taki racjonalny kompromis między magicznymi metodami ORMów odwołujących się beztrosko do schematu bazy, a topornymi zapytaniami SQL wstrzykniętymi perfidnie w kod. Mówię tutaj o takiej koncepcji jaką można spotkać w ZF1. Może i mamy nadmiarowe odwołania do funkcji, ale owe funkcje jednocześnie odpowiadają za sprawną konkatenację fragmentów zapytania oraz ochronę przed SQL Injection.

co do query builderow - zwracają o kilka zapytań wiecej do bazy niz standardowe zapytanie - defakto spowalniając działanie apki i ta teza jest bezsporna

W jaki niby sposób ? Podałem konkretnie o jaki rodzaj query builderów mi chodzi. Sugeruję najpierw zapoznać się z zasadą działania, a potem dopiero rzucać takie teorie. Wystarczy zbadać kod klasy Zend/Db/Table/Abstract.php, aby zobaczyć w jaki sposób wywoływane jest zapytanie. Metody fetch*(), a konkretniej chroniona _fetch() się kłaniają. Tam wlatuje obiekt select i wywoływany jest magik parsujący do stringa. Dalej operacje lecą w oparciu o dane API dostępu do bazu, zupełnie tak jakbyśmy korzystali ręcznie np. z PDO.

Query builder w tym znaczeniu, to tylko ładne opakowanie dla zwykłego stringa, a nie żaden active record.

Temat: Fromewroki a ciężka praca

Radosław S.:

Paweł L.:

Co do "query builderów" - nie są takie złe. Powiedziałbym, że mamy tutaj taki racjonalny kompromis między magicznymi metodami ORMów odwołujących się beztrosko do schematu bazy, a topornymi zapytaniami SQL wstrzykniętymi perfidnie w kod. Mówię tutaj o takiej koncepcji jaką można spotkać w ZF1. Może i mamy nadmiarowe odwołania do funkcji, ale owe funkcje jednocześnie odpowiadają za sprawną konkatenację fragmentów zapytania oraz ochronę przed SQL Injection.

co do query builderow - zwracają o kilka zapytań wiecej do bazy niz standardowe zapytanie - defakto spowalniając działanie apki i ta teza jest bezsporna

W jaki niby sposób ? Podałem konkretnie o jaki rodzaj query builderów mi chodzi. Sugeruję najpierw zapoznać się z zasadą działania, a potem dopiero rzucać takie teorie. Wystarczy zbadać kod klasy Zend/Db/Table/Abstract.php, aby zobaczyć w jaki sposób wywoływane jest zapytanie. Metody fetch*(), a konkretniej chroniona _fetch() się kłaniają. Tam wlatuje obiekt select i wywoływany jest magik parsujący do stringa. Dalej operacje lecą w oparciu o dane API dostępu do bazu, zupełnie tak jakbyśmy korzystali ręcznie np. z PDO.

Query builder w tym znaczeniu, to tylko ładne opakowanie dla zwykłego stringa, a nie żaden active record.

racja, nie doczytałem twojego posta, myslalem ze ciagle poruszamy sie w tematyce yii i AR a nie zf1

Temat: Fromewroki a ciężka praca

Plusem dużych frameworków, jak SF2 czy ZF2 jest to, że jak się nauczysz z nich korzystać i je zrozumiesz to z dużym prawdopodobieństwem znajdziesz dobrze płatną pracę, szczególnie w większych firmach czy w dobrych software house'ach. Tego typu firmy nie mogą sobie pozwolić na tworzenie aplikacji, czy serwisów w niszowych frameworkach, a tym bardziej w czystym PHP.