Continuarea discuției de aici
@yox64 ma bucur ca intre timp ti-ai dat seama ca performanta frameworkului nu e cel mai important lucru (desi e in top5, as zice eu). E important felul in care structurezi totul, pt nu a ajunge la legacy. Apoi, e la fel de important ca acel cod pe care il scrii sa fie cu un nivel de abstractizare deasupra frameworkului, ca sa poti usor schimba o librarie neperformanta/ cu gauri de securitate/ etc.
The amount of work in order to properly do that will equal the cost of creating your own framework.
Lucrez pe PHP 7 de la aparitie si consider ca e foarte important ca framework-ul ales sa suporte PHP 7, mai ales daca te intereseaza performanta.
sunt de acord cu tine.
cand ai spus despre schimbarile de librarii neperformante, consideri esential ca aceasta schimbare sa se faca prin composer? sau cum te-ai gandit la procesul asta de schimbare al unei librarii?
imi poti da ceva exemple concrete sau mai multe detalii?
Ai intuit exact ideea mea de a lasa definirea dependintelor in seama unui package manager. In lumea php el este azi composer.
Asadar un upgrade de librarie inseamna
Suntem in dezacord legat de costul acesta. Nu scriem chiar un framework intreg, doar separam f bine middleware-ul de restul aplicatiei. In felul acesta putem lega atat un web interface, cat si un mobile app la middleware-ul nostru, reducand astfel dramatic costurile pe termen mediu si lung.
Exemplu concret: trimiterea de mailuri.
Caz 1 (hardwired): se foloseste mail() care vine la pachet cu phpul. Developerul apeleaza direct din controller functia respectiva.
Caz 2 (folosirea unei librarii externe): se instaleaza Swiftmailer si se modifica in controllerul din exemplul anterior.
Caz 3 (folosirea middleware): se creaza un serviciu al aplicatiei care trimite mailuri. El e folosit cu metoda dependency injection in controller. In felul acesta, se refoloseste acest middle layer, si se poate merge mai usor.
Exemplele de mai sunt doar “decent OOP practices” de ce nu zici asta in loc de “… acel cod pe care il scrii sa fie cu un nivel de abstractizare deasupra frameworkului”? Semantic nu sunt echivalente.
Interesant.
Problema de care m-am lovit momentan e ca CI nu e composer-friendly, update-ul la framework se face mai manual… Desi, pentru alte librarii pot folosi fara problema.
Consideri ca e esential ca si framework-ul sa treaca prin composer? in CI exista ceva solutii, dar nu e nativ
Eu recomand CodeIgniter ca pas intermediar pentru a putea trece la un framework puternic.
CI are un manual foarte bine scris, si ajuta la clarificarea multor concepte.
Apoi, dupa stapanirea notiunilor de baza, se poate trece la Symfony / Zend / microframeworks (NU Laravel).
Cu siguranta da. Dependintele nu trebuie adaugate in repository nostru de cod, ci declarate ca atare si adaugate prin instalare de catre dependency manager.
Sa stii ca multi din cei care scriu cod folosind frameworkuri o fac direct in controller. De aceea consider ca trebuie clarificate acceste aspecte de fiecare data cand am ocazia. In timp, vor invata sa isi faca singuri aceste layere de “business logic”, dar e f greu pt cineva care alege frameworkul (si e, deci, mai incepator) sa faca direct chestiuni care noua ni se par a doua natura.
Hey tekkie. De ce NU Laravel?
La fel ca si @dabuno sunt si eu curios de ce esti asa de categorica in privinta Laravel-ului, nu ca te-as contrazice sau ceva 
De asemenea, ce microframework-uri recomanzi?
Pentru ca este o clona de Rails iar Rails este the epitome of bad design and slug fest performance
Ok, complet de acord insa cum ii ajuta asta?
Deja suna un pic contradictoriu, de la: nivel de abstractizare deasupra frameworkului am ajuns la: ... care noua ni se par a doua natura.
Daca nu lasam comentariul initial de unde a pornit acest sub-thread, partea cu abstractizari ramanea ceva vag si nedefinit
Stiu, stiu sunt un semantic nazi, recunosc.
Eu am stat departe de Laravel pentru ca foloseam deja Symfony cand aparut si nu mi-a placut faptul ca soarta frameworkului sta in mana unui singur om (Taylor, care a facut o treaba excelenta la capitolul marketing pentru framework si de aici si popularitatea lui). E Laravel un fremwork prost? Nu cred, cel putin teoretic se prizinta foarte bine.
@dakull slim controllers (glue code) and fat models/services/managers este un concept destul de simplu si cred ca la asta le referea @tekkie. Ca incepator care abia invata un framework esti tentat sa iti pui tot codul in controller si gata. Middleware suna complicat, dar nu e dracul chiar asa de negru (depinde bineinteles de complexitatea aplicatiei).
Symfony a primit la un moment dat o sectie de best practices care e menit sa te ajute sa faci lucrurile mai bine dupa ce te-ai familizat un pic cu frameworkul.
Am sa incerc sa ma explic, dar o sa iasa probabil mai mult text decat mi-as dori, sper sa se inteleaga. De asemenea, doresc sa intaresc faptul ca parerile exprimate mai jos sunt ale mele, probabil veti gasi alti seniori care va vor recomanda calduros Laravel. Aici se deschide deja alta discutie.
Laravel este scris peste componente Symfony, la care s-au adaugat niste moduri mai putin ortodoxe de a scrie cod (apelari de metode statice). Acest lucru il face foarte usor de folosit de incepatori, dar e impotriva principiilor de programare curata. Practic te incurajeaza sa scrii cod prost. Cam asta e principala mea problema cu el.
Al doilea motiv este faptul ca Laravel are propriul ORM, nici macar nu foloseste Doctrine care e mai bine testat in aplicatiile serioase. Deschidem manualul Laravel sa ne uitam cum se recomanda folosirea ORMului si vedem direct un foarte tight coupling intre model si sursa de date:
class User extends Model {
protected $table = 'my_users';
}
Aceasta abordare incalca din nou extrem de multe principii de programare clean, pentru care ar fi nevoie de o carte intreaga sa le explicam pe indelete. E suficient sa amintim faptul ca modelarea conceptelor aplicatiei trebuie sa fie complet decuplata de sursa de date, tocmai ca sa poti aduce modificari oricareia dintre acestea fara sa ti se sparga totul in brate.
Tot la partea de ORM din Laravel (daca ne calcam pe inima si o folosim) observam ca ofera, f convenabil pt rapiditatea codarii functionalitatii, many-to-many. Cand am vazut prima data “Polymorphic Many To Many Relation” marturisesc… am inchis pagina de la browser. Am vazut astfel de lucruri scapate de sub control de multe ori, si se datoreaza in primul rand comoditatii dobandite in urma faptului ca lasam pe altii (ORMul) sa scrie interogarile pt noi. Se ajunge la (1) interogari f lungi si greu de debuggerit; (2) extragerea mult prea multor date din DB fara sa fie necesar acest lucru.
Mersi @redecs pentru clarificarea legata de ownershipul Laravel, e foarte importanta in economica scrierii unor aplicatii care vrem sa “ne țină” cat mai mult. Sa nu uitam ca Symfony a primit bani (si nu putini) sa stabilizeze un produs deja bun, si-au facut echipa cu oameni reductabili din toata Europa, etc. Pe de alta parte, daca pica in Atlantic avionul in care e Taylor Otwell…
Ar mai fi un argument de luat in seama. Laravel face upgrade-uri furioase de versiuni majore. Asta inseamna ca nu poti beneficia de “latest and greatest” fara sa ai breakward compatibility issues. Mai sunt si altii ingrijorati, https://gist.github.com/anonymous/8565929 e doar un exemplu. De aceea trebuie ca acel cod al aplicatiei noastre sa aiba o dependinta minimala de frameworkul folosit, ca sa ne putem replia usor, si nu rescriind tot.
Am uitat sa specific: Taylor a facut Cobol si .NET / ASP (asa cum zice chiar el) inainte sa se mute la PHP. Bazele pe care a cladit nu sunt cele mai bune.
E un bun marketer al muncii sale? Categoric. E un programator peste medie (ex: Uncle Bob, Cal Evans, MWOP, Fabien)? Eu cred ca nu.
Daca vreti cod curat intr-un framework one-man show va recomand Aura. Paul M Jones stie sa faca niste cod minunat.
@tekkie observ foarte multe predispozitii negative deoarece codul este impur sau ca este owned by one dude care este mediocru ca programator (not sure dupa ce standarde).
Purismul arhitectural nu duce nicaieri poate doar la generarea unui meta-framework (ceea ce ziceam si mai sus).
Da, trebuie sa folosim good OOP practices insa nu sa le fortam doar din prisma unui purism OOP inexistent.
Eu unul prefer varianta pragmatica/realista a lui Sandi Metz si anume ca nu exista cod pur in the real world si de foarte multe ori contextul nici nu-ti permite sa-l generezi. Cand il fortezi o sa ajungi la some over-engineered piece of garbage (in variantele extreme ofc).
IMHO: OOP is not idealism nor is it maths.
Te inteleg perfect. Mai stiu si cum arata o zi de lucru dupa multe luni in care am ignorat (ca echipa) bunele sfaturi ale tuturor.
Asa cum am zis si mai sus, sunt parerile mele. Mi le intemeiez pe multa munca si pe nopti nedormite. Ca pe viitor sa pot lucra cu placere, am invatat unele lectii pe care incerc sa le ofer si altora.
Consider ca baza pe care scriu cod este foarte importanta, de aceea ma uit la posibilele probleme din timp. Nu e vorba de cod impur, ci de sanatatea noastra pe termen mediu si lung, Eu vreau sa petrec timp cu prichindelul meu in parc in loc sa debuggeresc cine stie ce minuni.
well, that’s real motivation frumos!