PHP pur vs Frameworks

In ultimii ~3 ani am ajuns sa cred ca framework-urile sunt ceva obligatoriu. Ce sens ar avea sa reinventezi roata, sa-ti scape o gramada de probleme (mai ales cu securitatea nu e indicat sa te joci), sa pierzi timp facand ceva deja existent?

Am gasit un rol bun unui framework chiar si la proiect mai mici. Ce bine ma simteam ca scap de o serie de verificari (isset), data escape la db queries, db queries in care mai uiti o virgula, revii etc.

In urma cu ~o luna am avut nevoie de un sql query ceva mai complex si, fiind mai nou in Doctrine, am zis sa gandesc treaba ca “pe vremuri”, deschid pma si incep sa scriu sintaxa… Si bang! Mi-am dat seama care e, cel putin in cazul meu, minusul in lucrul cu framework-uri: faptul ca uit bazele. Unii vor spune “Asa, si? De ce te-ai intoarce la baze?”. Raspunsul meu se imparte in doua:

  1. Pentru simplul fapt ca unele solutii sunt mai complexe si nu merge sa scrii doua linii de cod intr-un framework.
  2. Nostalgie. Imi placea cand scriam si rescriam cod, de fiecare data intelegeam mai bine ce se intampla (nu am avut norocul ca toate proiectele sa aiba atat de mult timp disponibil incat FIECARE solutie sa fie perfect studiata, deseori era “cod facut sa mearga”; intr-o oarecare masura imi asum asta, e si vina mea)

Ieri am fost la un interviu si cand mi s-a spus ca proiectul e in PHP pur, m-a cam gadilat.

Ce vreau de la voi? Experienta/parerea voastra cat mai obiectiva pe subiect.

3 Likes

Cum discutam si in alt topic, composerul a dat jos ideea de framework. Acum poti folosi o librarie de routing sau una db sau una de ORM, fara sa fii fanatic pentru un framework anume.

Eu unul am lucrat cu un framework propriu, cateva librarii proprii, iar restul www de circa 10 ani. Composerul mi-a facut viata mai frumoasa in a tine la curent “flavor”-ul prin care dezvolta.

In ceea ce priveste ORM-urile (Doctrine, Propel ,etc) ele sunt solutii punctuale in anumite situatii (chiar limitate as zice eu), si nu o chestie de esti cool sau nu.

In ceea ce priveste clasa proprie de db, o folosesc de vreo 15 ani: cu escape & other stuff, si nu am vazut sa se schimbe multe. Intr-adevar am updat-o la tehnologii noi.

In ceea ce priveste framework-urile moderne: laravel mi se pare cel mai apropiat de stilul meu de lucru, desi nu am aplicatii in productie publica.

2 Likes

Primii 4 ani ca webdeveloper am lucrat numai cu chestii făcute de zero de mine + librării (gen lightbox, jquery etc). După acea am început să lucrez cu framework (schimbat jobul). Satisfacția e mare când implementez chestii complicate foarte repede și nu mai trebuie să-mi bat capul cu chestii care le-am făcut deja de o mie de ori înainte.

Nu simt că am uitat să scriu PHP pur. Din când în când îmi place să fac extensii de la zero pentru framework-ul în care lcurez. Plus că sunt multe aspecte din framework-ul pe care-l folosesc care nu-mi plac (mi se par că sunt over engineered și atunci prefer să-mi scriu eu un modul de la zero care să facă exact ce am eu nevoie).

Query-uri complicate încă mai scriu când vreau să verific chestii sau când fac rapoarte în legătură cu ce date sunt corupte (se mai întâmplă să găsim bug-uri și vrem să știm cam cât de multe intrări au fost afectate). Dacă nu fac asta la lucru, tot mai scriu PHP pentru scripturi personale.

Partea nasolă la proiectele pur PHP e că uneori numai developer-ul principal le înțelege (de aia clienții preferă framework-uri că pot pasa proiectul mai departe la alt developer dacă e nevoie). Iar dacă e un framework intern mă aștept să dai de niște cod WTF pe ici pe colo (dacă nu e chiar tot framework-ul așa - cum mi s-a întâmplat la prima firmă la care am lucrat).

1 Like

as vrea sa vad si eu proiectul ala unde un orm este limitat. proiectul ala unde ai mai mult de 30% interogari care nu se pot rezolva cu ce stie sa faca orm-ul (vorbim de un orm care nu stie sa ruleze interogari scrise de tine, nu?).

composerul a dat jos ideea de framework? rili?

eu am uitat cum sa fac interogari direct din php. in rest n-ar trebui sa ai probleme. un fw te ajuta sa scrii cod mai repede, dar tot trebuie sa cunosti limbajul de programare. nu-i ca si cum uiti ce face isset.

Asa pare pentru mine, sau cel putin le-au subtiat foarte mult pentru ca nu mai ai nevoie sa apara un framework care are de toate: si cache si rss feed-uri, etc, fiind foarte usor sa integrezi alte librarii mult mai bine facute pentru probleme punctuale.

Nu am zis ca ORM-ul este limitat, am zis ca situatiile unde ele sunt cele mai eficiente sunt limitate. Majoritatea ORM-urilor par sa faca destul de mult , asa ca nu ma gandesc ca sunt limitate.

1 Like

Pt. discutiile de genul, recomand: Simple made easy

ORM-urile te limiteaza, indiferent ca-ti convine sau nu, creaza inca un layer de complexitate peste DB pe care trebuie sa-l inveti, sustii, si uneori sa implementezi in jurul lui ca sa obtii ce vrei.

your code >> ORM >> DB api >> DB storage

Am intalnit (destul de des) persoane care folosesc ORM-uri ca nu vor sa invete capabilitatile DB-ului folosit, asa ca sa bazeaza pe un ORM sa abstractizeze DB-ul cu totul.

Personal am invatat pe barba mea, am folosit Doctrine in php si apoi cand am inceput Node.js am folosit Mongoose, ca sa fiu in ton, ulterior mi-am dat seama ca nu se merita cand te apuci si citesti documentatia de la DB.

Folosesc doar un ORM, RedBeanPHP si la unele chestii, chiar am aruncat cod SQL scris de mana pentru ca inca nu prea am stat sa folosesc/invat Redbeanu asa de mult.

La fostul job, mi se parea overkill cand foloseau bartai codingniter pentru un amarat de LP, asa ca preferam ceva mai simplu, un fisier care facea toata treaba (stoca in db si trimitea un email).

Ma doare inima cand aud ca un ORM te limiteaza sau ca face munca mai grea.

Problema cea mai mare intalnita de mine la site-urile fara un ORM este despre relatii.
Avem un User, un user poate sa aibe mai multe Post-uri. Relatia sigur e o coloana, care e aceea? Este user_id, id_user, owner sau utilizator?

Peste doua ore ai nevoie din nou de aceeasi relatie. Trebuie sa cauti din nou coloana de legaura. Destul de mult munca, huh?

La securitate, am avut query-urile securizate contra SQLi inca din primele zile de scis cod.
Nu cred ca securitatea este o problema in ziua de azi daca nu esti idiot.(accidentele sunt exceptii)

ei prefera sa scrie de 1000 de ori aceleasi interogari complicate si sa prelucreze de 1000 de ori datele doar pentru ca au intalnit cateva cazuri in care orm-ul nu se descurca. de fapt nu-s in stare sa evolueze. nu inteleg prea bine de ce-i $this si nu $that. nu pricep cand sa foloseasca -> si cand sa foloseasca ::. se incurca la private si protected. din cauza asta oop-ul, frameworkurile si orice altceva care iti usureaza munca sunt “naspa, complexe, fara nici un rost, depasite”.
majoritatea lucreaza haotic, n-au nici o logica in cod, se uita cu dispret la tine cand le spui ca logica n-are ce cauta in view-uri si li se pare perfect normal sa copie cod dintr-o parte in alta.

da, asta-i un post scris la nervi. tocmai am de-a face cu codul unuia care s-a gandit ca o roata patrata e mai buna decat una rotunda din cauza ca n-are cum sa se duca la vale.

3 Likes

Prefer lucrul cu framework (ZF2). Nu vad nici un minus, atata timp cat ii inteleg structura si modul de lucru. Dar trebuie sa adaug ca pana anul trecut preferam sa scriu tot codul de la 0 (imi scrisesem chiar si un mini-framework MVC), chiar daca un proiect imi lua de 10-20 de ori mai mult decat acum. In felul asta am ajuns sa inteleg mai bine unele concepte. Acum nu m-as mai intoarce niciodata la programarea fara un framework.

Legat de ORM-uri: inca n-am folosit unul, pentru ca inca-mi place sa ma joc cu interogarile / sa am control direct asupra lor.

@alescx Din ce inteleg, e un post scris la nervi. Dar nu cred ca e ok sa tragi astfel de concluzii… Decizia de a nu folosi o anumita unealta nu cred ca are de-a face cu lipsa de evolutie sau cunostinte.

Eu programez de vreo 8 ani, am inceput cu PHP si am folosit: Zend Framework, CodeIgniter, Symfony, Symofny 2, Silex, Laravel (recent); ca ORMs: Doctrine si Propel.

Ulterior am trecut pe Node.js si am inceput cu Geddy.js, Flatiron.js, Express.js, Koa (recent); ca ORMs: Sequelize.js si Mongoose.js.

In Go si Ruby sunt incepator, cu toate ca am facut cateva lucruri nu as putea sa le trec ca si experienta.

Dupa ce treci prin mai multe frameworks incepi sa-ti faci o idee ce te ajuta si ce nu (subiectiv).

Eu va recomand sa incercati mai multe frameworks (chiar si mai multe limbaje de programare), ca sa va faceti o idee.

Eu vreo 4 ani am zis ca nu am timp sa experimente ca am volum “mare” de lucru. Dupa ce inveti si alte sisteme incepi sa si inveti ce si unde sa cauti, iar ca freelancer mi-a fost de ajutor, deaceea recent am inceput sa invat Go.

P.S. - ar fi interesant sa povesteasca cineva tranzitia de la php la node.js si cat i-a costat un framework in-house si incapatanarea de a experimenta timp de 1 an (ca sa nu dau nume :smile:)

2 Likes

Ce zici de bypass-uri? Nu sta tot intr-un mysql_real_escape_string sau un htmlentities.

La ce bypass-uri te referi? Inca nu l-am vazut pe ala sa treaca de un ENT_QUOTES.

@IonutBajescu sa stii ca pe unii ii limiteaza ORM-ul. Sunt cei care inca prefera sa faca 2 select ca sa “nu se complice” cu un join. Da, pe ei ii limiteaza! Si ei chiar cred asta, din pacate - am intalnit foarte multe cazuri de genul asta; mai trist e ca multi dintre ei erau in posturi in care-si permiteau sa dicteze noilor angajati cum sa faca lucrurile - caz in care totul devine cu multe grade de magnitudine mai trist.

Ah, si inca un punct: tot “ei” sunt cei carora data integrity nu le spune nimic; ei nu folosesc foreign keys, nu fac relationships si nu au constraints, pentru ca “fac asta din cod”.


Cat despre preferinta mea, totul e clar: zicea cineva mai sus de un landing - eu l-as face cu Jekyll (care scoate incadrarea din zona php) daca e chiar 100% static. Daca are cea mai mica logica, prefer sa pun un framework chiar si pentru o singura pagina.

De ce?

  • Pentru ca am toate variabilele setate, am environments si nu ma complic cu hardcodari pentru a-l rula local
  • Pentru ca e “that easy”
  • Pentru ca de la “un simplu landing” mai adaugam un formular de contact, un admin ca sa colectam formularul, un daily feed al formularului trimis la adresele X si Y, mai adaugam un al doilea landing cu url-ul “/noul-landing”, mai adaugam un formular; ni se spune ca vine spam pe formular, mai adaugam un recaptcha si un csrf; cam de-asta.
  • Pentru ca vine un angajat nou si singura modalitate e sa folosim ceva cu guideline-uri clare, cum ar fi… MVC
  • Pentru ca in noua versiune de php functiile mysql_* vor genera o exceptie si pentru ca nu vreau sa-mi amintesc atunci in ce proiecte le-am scris - sîc!
  • Si mai sunt multe altele…
2 Likes

ORM-ul te poate limita in multe feluri si in plus esti nevoit sa inveti inca o modalitate de a face un lucru ce stii sa faci. Probleme concrete intalnite cu Doctrine 1.x, 2.x, Propel 1.x:

  1. migrari de date - probleme de leakuri de memorie cauzate de referinte circulare, in cazul unui set mare de date devine o problema.
  2. viteza
  3. Probleme specifice Doctrine 2:
  4. Lazy loading pentru entitati care au relatie de 1:1
  5. Entity manager “blocat” dupa o eroare la o operatie low level de DB
1 Like

Eu sunt 100% de acord cu omu’ https://www.youtube.com/watch?v=anr7DQnMMs0
http://www.phpclasses.org/blog/post/226-4-Reasons-Why-All-PHP-Frameworks-Suck.html

1 Like

Nu stiu de ce lumea il idolatrizeaza asa de mult pe individul asta. Pana si el o spune cu gura lui ca a inceput sa lucreze la PHP pentru ca “Perl era prea greu” - si cred ca suntem cu totii de acord ca sa inveti si sa lucrezi cu Perl e mai usor decat cu multe alte limbaje.
Lui Lerdorf ii place procedural - de asta a si inceput sa lucreze la “Personal Home Pages”, pentru ca vroia ceva simplu - mai simplu decat Perl. E evident ca o sa urasca orice framework care adauga complexitate peste jucaria lui.
Sad, sad puppy…

Lerdorf wrote PHP in 1993 to handle simple interactive tasks such as one with the ability to query a user and generate a form based on the results. But at the time, “the amount of code you needed to write just wasn’t feasible,” Lerdorf said. He tried using Perl, but writing HTML code within a Perl program was difficult for him, given the syntax rules of Perl. So, he used Perl to build his own language. “This simple thing turned out to be what PHP is today,” he said. - Sursa

3 Likes