Indhold
Spørg mig, hvilken ramme jeg skal bruge, og jeg vil sandsynligvis have et gnaven gammeldags øjeblik og fortælle dig, at alle rammer er lige så dårlige som hinanden. Hvilket ikke vil sige, at de alle er dårlige, nøjagtigt, men i PHP har vi et utænkeligt stort antal rammer (normalt citeret som N + 1, hvor N er antallet af PHP-udviklere i verden), og de har sandsynligvis alle givet mening til den person, der opfandt dem.
At have et valg af rammer er sandsynligvis bedre end at forsøge at bruge kun en ramme, uanset hvad du nøjagtigt prøvede at bygge, fordi det er den 'bedste' (uanset hvilken målestok 'bedste' er). Dette udvalg af rammetilbud betyder, at du kan vælge noget, der opfylder projektets behov, og det kan endda dokumenteres. Rammer på enhver platform er virkelig der for at give struktur, genanvendelige moduler og biblioteker og generelt undgå alle de kedelige og gentagne opgaver at gøre med at opbygge den samme funktionalitet igen og igen. For eksempel når der opbygges CMS'er, skal noget behandle og validere formularfelter for mig; hvis jeg overlader til mine egne enheder, går jeg måske glip af noget vigtigt, og jeg vil hellere gøre de elementer i hvert projekt, der er forskellige, snarere end dem, der er de samme hver gang!
Full-stack rammer
Full-stack-rammer, såsom Zend Framework, kan være et godt sted at starte for en udvikler uden meget arkitekturoplevelse. Det giver god struktur at hænge en ny applikation på, og der er et godt 'økosystem' omkring det - masser af bøger, vejledninger og noget rimelig dokumentation også. Hvis du forsøger at opbygge en stor applikation, som vil blive vedligeholdt af mange mennesker, er en populær, omfattende ramme sandsynligvis et godt valg, da det vil diktere en hel del struktur og være velkendt og forstået.
At have struktur til at hjælpe med adskillelse er altid godt; tidligt i min karriere arbejdede jeg med nogle meget juniorudviklere og forsøgte at lære dem MVC-mønsteret (Model View Controller), som på det tidspunkt var relativt nyt. Vi tog beslutningen om at bruge Smarty i visningslaget; dels for at designerne lettere kunne arbejde med skabelonerne, dels for at når nogen kom til mit skrivebord og sagde "hvordan gør jeg X med Smarty?" Jeg kunne sige "gør ikke X i udsigten!" (ni gange ud af 10 var det svaret). At have rammer hjælper os med at finde den samme adskillelse i andre dele af vores applikation. Mange af dem understøtter integrering mod et skabelonlag som Smarty eller min nye favorit, Twig, så du kan tage disse værktøjer med dig, uanset hvilken ramme du vælger.
Lys belastningen
Der er masser af lettere rammer end Zend Framework, for eksempel arbejder jeg ganske lidt med CodeIgniter. Er det så omfattende og robust som Zend Framework? Nej, det er det ikke. Men som en hjælperamme, der gør det muligt hurtigt at opbygge en applikation, er det nyttigt. Generelt kan rammer med mindre 'hjælper'-funktionalitet være lettere at finde rundt, da det er meget mere tydeligt, hvordan brikkerne går sammen. I en ukendt ramme (for mig er det stort set alt), er det de automatiske bits, der gør det svært at arbejde med og fejlfinde.
Den følelse af at være "tabt i en ny ramme" er uundgåelig og fuldstændig frustrerende; selv en erfaren udvikler føles som en nybegynder, når de ikke ved, hvordan noget fungerer. Hvis du virkelig er uheldig, har du valgt en ramme, hvis IRC-kanal fortæller dig, at du også er en idiot! Det er denne meget negative indledende oplevelse, der afskrækker mange mennesker fra at bruge en ny ramme eller vedtage en i første omgang, og meget få rammer gør et godt stykke arbejde med at hjælpe nye brugere over den indledende forhindring.
I PHP har vi også nogle rammer, der ikke rigtig er rammer på den måde, som jeg normalt bruger ordet. Vi har nogle dejlige komponentrammer; samlinger af biblioteker designet til at blive brugt efter ønske og til at spille pænt sammen, såsom Zeta Components (tidligere eZ Components) og Symfony Components (har du set deres side? De vinder prisen for bedste illustrationer!). Det bedste og mest undersung af disse er naturligvis PHPs egne PEAR- og PECL-tilbud - på en eller anden måde bliver disse glemt i denne modige nye verden af rammer.
Microframeworks
Microframeworks er en voksende tendens i PHP; Dette er superlette tilbud, der bare hjælper dig med at lime ting hurtigere sammen. Et godt eksempel er Slim, som er meget hurtig og enkel at bruge og forstår RESTful koncepter. Det er baseret på ideen om 'ruter', som er URL-mønstre. Du registrerer en rute og giver et tilbagekald, som skal påberåbes, når der anmodes om denne URL.
De fleste PHP-udviklere vedtager en ramme og holder fast ved den, eller de bruger måske en på arbejdspladsen og en anden til deres hobby- eller open source-projekter. Der er ringe enighed om den "bedste" ramme, der skal bruges, så alle holder sig bare til det, de ved, og resultatet er parallel udvikling af et stort antal rammer! Jeg elsker at have et valg at vælge imellem, men nævnte jeg, at de alle er lige så dårlige som hinanden?
Hvis du kender Zend Framework, ender du med at beskrive dig selv som en Zend Framework-udvikler; du ville ikke være komfortabel med at skrive i en anden ramme, før du havde haft en chance for at få fat i det, og du husker sandsynligvis ikke mange af de rå PHP-funktioner til ting, hvis du ikke bruger dem ofte. Denne idé om, at vi er blevet rammespecifikke udviklere, der kun arbejder oven på lag med abstraktion, er lidt underligt for PHP. Når alt kommer til alt er dette sproget "for at løse webproblemet". Det er skrevet i C og er et hurtigt, let sprog i sig selv ... forudsat at du ikke venter på, at en stor ramme-bootstrap-proces skal køre! Fra denne sammenhæng opstod MicroPHP Manifestet, skrevet af en mand, vi kalder Funkatron (selvom hans navn virkelig er Ed Finkler). Det er en række udsagn, der siger, at det er okay at opbygge et antal interoperable små moduler, at større ikke er bedre, og at livet virkelig er for kort til Java - selvom det er skrevet i PHP.
