Chestiile astea sunt S.F. pentru vreo 90% dintre „programatori” mai ales când vine vorba de ăia angajați pe Upwork (unde activez momentan).
Mie îmi place conceptul și probabil l-aș fi folosit dacă mi se părea că merită și fără a fi încadrat într-un framework. CakePHP oferă o serie de facilități (de exemplu face automat asocierile între tabele), însă n-ai cu cine. Mă rog de luni de zile să curățăm tabelele de indecși și coloane inutile și să normalizăm un tabel de 40 de coloane, 30+ indecși și vreo câteva zeci de milioane de intrări și care își schimbă datele în totalitate la fiecare 48 de ore. Dar nu. Că „merge”.
Și acuma vor pe baza acestui tabel să dezvolte un întreg ecosistem. Și când va pica totul, cine va fi vinovat? Red, exact.
Articolul postat de OP in sine este lipsit de substata. O insiruire de framework-uri si cate o parere aleatoare despre fiecare si aici o sa scriu doar cateva pentru exemplificare “VERY good Security features built-in” doar Phalcon are asta? "Very good for commercial web applications (MIT License) " doar CakePHP are acest “PRO”? “Ideal for enterprise applications · Object oriented” deci restul in afara de Zend sunt pt indivizi si procedurale?
Nu zice nimic de PSR…
Wow, ai scris multe chestii si inteleg ca poate esti frustrat, insa nu stapanesti anumite notiuni. Poate ar trebui sa mai aprofundezi putin - design patterns, linux procese si useri, network file sharing / mount, sql/nosql, web server config.
Nu cred ca esti singurul, personal am devenit mai circumspect cand vine vorba de folosirea unui framework si incerc sa ma lamuresc in ce masura ma ajuta sau ma incurca inainte de a adopta unul pentru un proiect sau altul.
Am avut multe experiente negative cu migrarea de date trecand printr-un layer intermediar de ORM (Propel 1 si Doctrine 2) incepand cu dependinte circulare intre obiecte asociate care nu permit eliberarea de memorie pana la entity manager care crapa si nu mai poate fi refolosit. Acuma intrebarea este daca am folosit “the right tool for the job” dar cel putin la momentul respectiv era varianta cea mai ok si nu era nimica in documentatie care sa te avertizeze ca voi avea probleme.
Sfatul meu este sa nu credeti tot ce scrie in documentatie si sa va lamuriti personal daca o tehnologie face ceea ce aveti nevoie sau nu.
Când am spus că acele lucruri sunt S.F. m-am referit că degeaba le știu eu dacă ceilalți programatori din echipă doar copiază ce am făcut sau pur și simplu nu înțeleg ce e aia și strică treaba două commit-uri mai târziu.
Există limitări și legat de cât pot înțelege ceilalți membri ai echipei.
Și apoi mi-am adus aminte de alte două probleme cu CakePHP (2 în acest caz).
Orice DELETE ceream, mereu detecta cheile primare și șteargea unul câte unul. Dacă aveam o condiție de genul: șterge tot ce are expiration_date în trecut, începea cu DELETE FROM tbl WHERE id = x, DELETE FROM tbl WHERE id = y.
Când am vrut să încarc 70.000 de intrări, am rămas fără memorie. Vroiam să populez un DataTable dintr-un foc, doar că fiecare rând fiind un obiect… Am folosit paginarea până la urmă, însă nu prea văd cum 70.000 de rânduri de 5 coloane de maxim 16 caractere trebuie să ocupe mai mult de 128 MB.
in cake2 rezultatele din interogari venea in forma de array. la fel le si inserai, tot ca array. abia din 3 a aparut conceptul de entity. deci nu, nu lucrai cu cate un obiect/rand.
la delete n-am vazut comportamentul de care vorbesti.
Eu sunt foarte curios care era performanța de afișare pentru datele respective. Am avut probleme la datatables de 1k intrări și cam de p-acolo încep să folosesc server side processing, dar 70k? LOL!
Nu pot lua ca și cuvânt al lui Dumnezeu nimic, cu atât mai puțin o comunitate de ~700 de oameni din care o parte fac PHP și o parte din aceștia lucrează cu framework-urile date.
Performanța pentru DataTables la 70.000 de rânduri? Nu știu. Un coleg, care a plecat de mult, a făcut o pagină care afișa vreo 500.000 de rânduri dintr-un json de vreo 5-6 MB. Și totul mergea foarte bine. Dar nu mai știu ce bibliotecă a folosit. Însă argumentul central rămâne: se poate.
E bine, ai vazut esentialul…
Design patterns - arhitectura aplicatiei - “Vreau să scriu o clasă independentă…”
Linux procese si useri - apache vs php-cli - “Permisiunea fișierelor. În Cake…”
Network file sharing / mount - WebDrive, NFS - “Un framework are mii de fișiere…”
SQL/NoSQL - abstractizare db - “Toate framework-urile suprascriu SQL-ul…”
Web server config - apache, nginx - “Dacă trebuie să fac o pagină simplă: „Mentenanță.”
consider ca marea majoritate s-au intalnit cam cu tot ce spui acolo. dar singura care tine de programare e partea cu design patterns. in rest, programarea nu inseamna doar servere web, baze de date si linux. poti sa fii expert in c++ (exemplu aleatoriu) si sa n-ai nici o idee de existenta apache.
daca ma apuc maine sa fac o aplicatie care sa ajute la debitare placilor de lemn o sa am nevoie de putine cunostinte despre prelucrarea lemnului. ce fac, ma apuc sa spun ca pentru programare tre sa cunosti tamplarie?
edit: am citit primul comentariu pe repede inainte. n-am inteles exact la ce te-ai referit.
Nu, concluzia nu este „se poate”, ci „se poate în unele cazuri”. Faptul că ție ți-a fost lene să faci server side processing pentru afilarea datelor respective nu înseamnă că librăria/framework-ul/whatever sunt proaste, ci doar că ție ți-a fost lene. Soluția nu este nici pe departe să te plângi, ci să folosești unealta corectă pentru ce ai de făcut.
DAR eu nu sunt programator și doar mai scriu cod de distracție, e foarte posibil să nu mă pricep.
Scuze, nu am vrut să spun lene în adevăratul sens al cuvântului, dar faptul că ai fost cumva obligat să gândești altă soluție nu mi se pare un lucru rău. Ba din contră, mi se pare că, în cazul particular pe care-l discutăm, ar fi fost best practice să muți logica pe server și să iei datele asincron, nu să încarci zeci de mii de rânduri în tabel din prima.
Iar aici discuția poate continua la nesfârșit vizavi de ce se poate întâmpla în aplicația respectivă. De exemplu, poate să crească enorm cantitatea de date, caz în care oricum ai avea probleme de resurse pe server.
Mai mult, înverșunarea împotriva framework-urilor poate e data și de faptul că nu ai lucrat cu unul care să fie pe placul tău. Da, în multe din situații va trebui să cam folosești tool-urile lor, o să ai unele limitări sau moduri de a face lucrurile specifice framework-ului, dar soluția nu mi se pare reinventarea roții, ci găsirea unei unelte pe placul tău. Evident, poți inclusiv să-ți faci propriul framework dacă asta e soluția pentru tine, dar și soluția asta are puncte tari și (multe) puncte slabe.
Ca o paralelă, e ca și cum aș spune eu că WP e o prostie pentru că eu nu mă ating de nimic făcut în WP (deși poate ar trebui, aș mai învăța una-alta). Nu, la fel ca și tine, am posibilitatea de a refuza proiectele pe acel codebase. Nu te poate obliga nimeni să lucrezi în Cake dacă ție nu-ți place.
Știți ce cred eu? Eu cred că prea multă politețe strică și mai bine i-ați spune omului adevărul: Amice, ești un novice!
Ori faci asta de prea puțin timp și n-ai avut încă timp să-nveți, ori ai lucrat prea mult timp singur sau înconjurat de unii și mai slabi ca tine, ceea ce te-a făcut să te crezi mai bun decât ești și să repeți aceleași greșeli ani la rând fără să înveți nimic.
Toate cele 13 puncte enunțate de tine mai sus nu sunt decât manifestări ale lipsurilor tale, și nu ale framework-urilor. Ar trebui să-ți dea de gândit faptul că oamenii care ți-au răspuns până acum nu au problemele enumerate de tine și poate încerci măcar să înveți un lucru sau două de la ei.
Ți le-aș explica eu pe toate dacă n-aș fi “naufragiat” cu doar un telefon la mine… O să răspund la una-două, ca să nu zică lumea că-s doar un bădăran, ca de obicei:
Framework-urile nu suprascriu SQL-ul ci îl generează. Pe lângă faptul că mai toate pe care le-am văzut permit scrierea de mână a query-ului, s-ar putea ca tu să nu știi să formulezi cum trebuie cerința folosind dialectul pus la dispoziție de framework. Cel puțin cel pe care-l folosesc eu îmi permite să fac query-ul complexe ce includ chestii precum group by, sub-select, agregarea și manipularea datelor folosind funcții MySQL, etc
Pentru că nu înțelegi că POST este doar verbul HTTP folosit și nu implică nici un fel de contract referitor la formatul în care vin datele ci doar la metoda prin care sunt transmise. PHP populează $_POST doar dacă vin într-un format (enctype) cunoscut de el iar JSON nu este unul. Pentru tot ce vine într-un alt format, datele sunt puse la dispoziție de PHP prin php://input iar ceea ce a trebuit să faci tu în Cake nu este decât un wrapper peste json_decode(file_get_contents('php://input')); iar acel wrapper este exact ceea ce trebuie să pună la dispoziție un framework.
Problema asta este în general rezolvată de framework-uri prin definirea de relații între modele de genul hasMany, belongsTo, etc. Învață să le folosești cum trebuie și scapi de artificii.
Dacă nu e nici una din alea, atunci locul ei e probabil în vendors, libraries sau cum s-o numi folder-ul în care framework-ul tău de așteaptă să găsească librării de la terți.
Majoritatea cu care am avut eu de-a face te lăsau să faci asta prin definirea unui data-source NULL. Ba chiar unele te lăsau să definești alte surse decât o bază de date, cum ar fi de exemplu un API. Li3 avea chiar un exemplu fain în care un model folosea API-ul Twitter ca sursă din care citea tweet-uri.
Framework-urile din ziua de azi nu prea mai instanțiază clase de care nu au nevoie. Cred că toate s-au aliniat la PSR și fac lazy-loading.
Pe lângă asta, dacă viteza e așa de importantă, atunci poate că un framework nu este unealta potrivită și ar trebui să încerci un micro-framework.
…și așa mai departe!
P.S.: Faptul că nu poți să porți o discuție atunci când interlocutorul îți spune că nu știi ceva e o problemă. Nu o să înveți niciodată dacă nu ești dispus să accepți că sunt lucruri pe care nu le știi, dar alții le-ar putea ști!
P.P.S.: Ar mai trebui să-ți dea de gândit și faptul că mesajul în care enumeri problemele a primit like-uri în cea mai mare parte de la oameni care s-au declarat ei înșiși începători. Ce zice asta despre tine atunci când problemele tale sunt unele la care se pot raporta începătorii?
Poti, te rog, cand nu mai esti naufragiat, sa completezi lista?
Habar nu aveam de faza cu php://input si, cum nu prea m-am atins de framework-uri, chiar sunt curios ce rezolvari ar avea celelalte probleme puse in discutie de @RedGuard
De unde era sa stie ca persoanele care i-au dat like sunt incepatori, ori nu. Also, exposure matters. Spre exemplu, desi sunt incepator si stiam raspunsurile la 1 si 6 si presupuneam ca ar trebui sa existe un folder others pentru 3rd parties (nowadays, at least), ii inteleg si lui punctul de vedere. Poate este sau a fost obligat de codebase sa foloseasca versiuni obsolete ale framework-urilor, sau documentatia era lacking. Si mai sunt si cazurile in care documentatia are niste imbarligaturi sau “tooltips” care sunt uneori considerate ‘extra’, desi tind sa contina informatii critice, in unele cazuri complet random (sau asa pare).
@RedGuard Daca tot ai de-aface cu oameni slab pregatiti, ai putea sa incerci sa-i ajuti sa devina mai buni. In felul asta, ti-ai face treaba mai usoara.
