Conţinut
Întreabă-mă ce cadru să folosesc și probabil voi avea un moment de femeie bătrână morocănoasă și să-ți spun că toate cadrele sunt la fel de rele unul ca celălalt. Ceea ce nu înseamnă că toți sunt răi, exact, dar în PHP avem un număr inimaginabil de mare de framework-uri (de obicei citate ca N + 1, unde N este numărul de dezvoltatori PHP din lume) și toți probabil au avut sens persoanei care le-a inventat.
A alege o serie de cadre este probabil mai bine decât să încerci să folosești un singur cadru, indiferent de ceea ce ai încercat să construiești, deoarece este cel mai bun (prin orice măsură de „cel mai bun”). Această selecție de oferte-cadru înseamnă că puteți alege ceva care să răspundă nevoilor proiectului și poate fi chiar documentat. Cadrele de pe orice platformă sunt într-adevăr acolo pentru a oferi structură, module reutilizabile și biblioteci și, în general, pentru a evita toate sarcinile plictisitoare și repetitive legate de construirea aceleiași funcționalități de mai multe ori. De exemplu, atunci când construiți CMS-uri, ceva ar trebui să proceseze și să valideze câmpurile de formular pentru mine; dacă sunt lăsat pe propriile dispozitive, pot pierde ceva important și aș prefera mult să fac elementele fiecărui proiect care sunt diferit, mai degrabă decât cele care sunt la fel de fiecare dată!
Cadruri full-stack
Cadrele full-stack, precum Zend Framework, pot fi un loc plăcut de început pentru un dezvoltator fără multă experiență în arhitectură. Oferă o structură bună pentru a agăța o nouă aplicație și există un „ecosistem” bun în jurul său - o mulțime de cărți, tutoriale și o documentație rezonabilă. Dacă încercați să construiți o aplicație mare care să fie întreținută de o mulțime de oameni, atunci un cadru popular și cuprinzător este probabil o alegere bună, deoarece va dicta destul de multă structură și va fi bine cunoscut și înțeles.
A avea structură care să ajute la separare este întotdeauna bun; la începutul carierei mele am lucrat cu unii foarte dezvoltatori juniori și au încercat să le învețe modelul MVC (Model View Controller), care era relativ nou la vremea respectivă. Am luat decizia de a folosi Smarty în stratul de vizualizare; parțial pentru ca proiectanții să poată lucra cu șabloanele mai ușor și parțial pentru ca atunci când cineva a venit la biroul meu și a spus „cum fac X cu Smarty?” Aș putea spune „nu face X în vedere!” (de nouă ori din 10, acesta a fost răspunsul). Având cadre ne ajută să găsim aceeași separare în alte părți ale aplicației noastre. Mulți dintre ei acceptă integrarea împotriva unui strat de modelare, cum ar fi Smarty sau noul meu favorit, Twig, astfel încât să puteți lua aceste instrumente cu dvs., indiferent de cadrul pe care îl alegeți.
Ușurați sarcina
Există o mulțime de cadre mai ușoare decât Zend Framework, de exemplu, lucrez destul de puțin cu CodeIgniter. Este la fel de cuprinzător și robust ca Zend Framework? Nu, nu este. Dar, ca un cadru de asistență pentru a permite construirea rapidă a unei aplicații, este util. În general, cadrele cu mai puține funcționalități de „ajutor” pot fi mai ușor de găsit, deoarece este mult mai evident modul în care piesele merg împreună. Într-un cadru necunoscut (pentru mine, asta este aproape totul), sunt biții automagici care îngreunează lucrul și depanarea.
Sentimentul de a fi „pierdut într-un nou cadru” este inevitabil și absolut frustrant; chiar și un dezvoltator experimentat se simte ca un începător atunci când nu știe cum funcționează ceva. Dacă sunteți cu adevărat ghinionist, veți fi ales un cadru al cărui canal IRC vă va spune că sunteți și un idiot! Această experiență inițială foarte negativă îi pune pe mulți oameni să nu mai folosească un cadru nou sau să adopte unul în primul rând și foarte puține cadre fac o treabă bună de a ajuta noii utilizatori să depășească acel obstacol inițial.
În PHP avem și câteva cadre care nu sunt într-adevăr cadre în modul în care eu folosesc de obicei cuvântul. Avem câteva cadre minunate pentru componente; colecții de biblioteci concepute pentru a fi folosite la voință și pentru a juca frumos împreună, cum ar fi Componentele Zeta (anterior Componente eZ) și Componentele Symfony (le-ați văzut site-ul? Câștigă premiul pentru cea mai bună operă de artă!). Cea mai bună și mai slabă dintre acestea este, desigur, propriile oferte PHP PEAR și PECL - cumva acestea sunt uitate în această nouă lume curajoasă a cadrelor.
Microframe
Microframeworks sunt o tendință emergentă în PHP; acestea sunt oferte super-ușoare care vă ajută doar să lipiți lucrurile mai repede. Un exemplu bun este Slim, care este foarte rapid și simplu de utilizat și înțelege conceptele RESTful. Se bazează pe ideea de „rute”, care sunt modele URL. Înregistrați o rută și dați un apel invers care ar trebui invocat atunci când este solicitată adresa URL respectivă.
Majoritatea dezvoltatorilor de PHP adoptă un cadru și rămân cu acesta, sau ar putea folosi unul la locul de muncă și altul pentru hobby-ul sau proiectele open source. Există puțini consens cu privire la „cel mai bun” cadru de utilizat, astfel încât toți să rămână doar la ceea ce știu și rezultatul este dezvoltarea paralelă a unui număr masiv de cadre! Îmi place să am o selecție din care să aleg, dar am menționat că toate sunt la fel de rele unul ca altul?
Dacă cunoașteți Zend Framework, atunci ajungeți să vă descrieți ca dezvoltator Zend Framework; nu te-ai simți confortabil să scrii într-un alt cadru până nu ai fi avut șansa de a te descurca cu el și probabil că nu îți amintești multe dintre funcțiile PHP brute pentru lucruri dacă nu le folosești des. Această idee că am devenit dezvoltatori specifici cadrului, care lucrează doar pe straturile de abstractizare, este puțin ciudată pentru PHP. La urma urmei, acesta este limbajul „pentru a rezolva problema web”. Este scris în C și este un limbaj rapid și ușor în sine ... cu condiția să nu așteptați să ruleze un proces mare de bootstrap de cadru! Din acest context a apărut Manifestul MicroPHP, scris de un om pe care îl numim Funkatron (deși numele său este într-adevăr Ed Finkler). Este o serie de afirmații care spun că este în regulă să construiești o serie de module mici interoperabile, că mai mare nu este mai bun și că într-adevăr, viața este prea scurtă pentru Java - chiar dacă este scris în PHP.
