Innhold
Spør meg hvilket rammeverk jeg skal bruke, så vil jeg sannsynligvis ha et gretten gammelt kvinneøyeblikk og fortelle deg at alle rammer er like dårlige som hverandre. Som ikke er å si at de alle er dårlige, nøyaktig, men i PHP har vi et utrolig stort antall rammer (vanligvis sitert som N + 1, hvor N er antall PHP-utviklere i verden), og de alle sannsynligvis ga mening til personen som oppfant dem.
Å ha et valg av rammer er sannsynligvis bedre enn å prøve å bruke bare ett rammeverk, uavhengig av hva du akkurat prøvde å bygge, fordi det er den 'beste' (uansett mål på 'best'). Dette utvalget av rammetilbud betyr at du kan velge noe som tilfredsstiller prosjektets behov, og det kan til og med være dokumentert. Rammeverk på hvilken som helst plattform er virkelig for å gi struktur, gjenbrukbare moduler og biblioteker, og generelt unngå alle de kjedelige og repeterende oppgavene som gjør å bygge den samme funksjonaliteten igjen og igjen. For eksempel når du bygger CMSer, bør noe behandle og validere skjemafelt for meg; hvis jeg overlater til meg selv, kan jeg gå glipp av noe viktig, og jeg vil heller gjøre elementene i hvert prosjekt som er annerledes, heller enn de som er like hver gang!
Full-stack rammer
Full-stack rammeverk, som Zend Framework, kan være et fint sted å starte for en utvikler uten mye arkitekturopplevelse. Det gir god struktur å henge en ny applikasjon på, og det er et godt ‘økosystem’ rundt det - mange bøker, veiledninger og litt rimelig dokumentasjon også. Hvis du prøver å bygge et stort program som vil bli opprettholdt av mange mennesker, er det sannsynlig at et populært, omfattende rammeverk vil være et godt valg, da det vil diktere ganske mye struktur og være godt kjent og forstått.
Å ha struktur for å hjelpe til med separasjon er alltid bra; tidlig i karrieren jobbet jeg med noen veldig juniorutviklere og forsøkte å lære dem MVC (Model View Controller) -mønsteret, som var relativt nytt på den tiden. Vi tok beslutningen om å bruke Smarty i visningslaget; dels slik at designerne lettere kunne jobbe med malene, og dels slik at når noen kom til skrivebordet mitt og sa "hvordan gjør jeg X med Smarty?" Jeg kan si "ikke gjør X i utsikten!" (ni ganger av ti, var det svaret). Å ha rammer hjelper oss å finne den samme separasjonen i andre deler av applikasjonen vår. Mange av dem støtter integrering mot et mallag som Smarty, eller min nye favoritt, Twig, slik at du kan ta verktøyene med deg uansett hvilket rammeverk du velger.
Lett lasten
Det er mange lettere rammer enn Zend Framework, for eksempel jobber jeg ganske mye med CodeIgniter. Er det like omfattende og robust som Zend Framework? Nei, det er det ikke. Men som et hjelperammeverk som gjør det mulig å bygge en applikasjon raskt, er det nyttig. Generelt kan rammeverk med mindre 'hjelper' -funksjonalitet være lettere å finne frem, ettersom det er mye mer åpenbart hvordan brikkene går sammen. I et ukjent rammeverk (for meg er det stort sett alt), er det de automatiske bitene som gjør det vanskelig å jobbe med og feilsøke.
Den følelsen av å være "tapt i et nytt rammeverk" er uunngåelig og helt frustrerende; selv en erfaren utvikler føler seg som en nybegynner når de ikke vet hvordan noe fungerer. Hvis du er veldig uheldig, har du valgt et rammeverk hvis IRC-kanal vil fortelle deg at du også er en idiot! Det er denne veldig negative førsteopplevelsen som får mange mennesker til å bruke et nytt rammeverk eller vedta en i utgangspunktet, og veldig få rammer gjør en god jobb med å hjelpe nye brukere over den første hindringen.
I PHP har vi også noen rammer som egentlig ikke er rammer på den måten jeg vanligvis bruker ordet. Vi har noen flotte komponentrammer; samlinger av biblioteker som er utformet for å brukes etter ønske og for å spille pent sammen, for eksempel Zeta Components (tidligere eZ Components) og Symfony Components (har du sett siden deres? De vinner prisen for beste kunstverk!). Det beste og mest understreket av disse er selvfølgelig PHPs egne PEAR- og PECL-tilbud - på en eller annen måte blir disse glemt i denne modige nye verdenen av rammer.
Mikroverk
Microframeworks er en voksende trend i PHP; Dette er superlette tilbud som bare hjelper deg med å lime ting sammen raskere. Et godt eksempel er Slim, som er veldig raskt og enkelt å bruke, og som forstår RESTful konsepter. Den er basert på ideen om ”ruter”, som er URL-mønstre. Du registrerer en rute og gir en tilbakeringing som skal påkalles når den URL-en blir bedt om.
De fleste PHP-utviklere vedtar et rammeverk og holder seg til det, ellers kan de bruke et på jobben og et annet til deres hobby- eller open source-prosjekter. Det er liten enighet om det "beste" rammeverket å bruke, slik at alle bare holder seg til det de vet, og resultatet er parallell utvikling av enorme antall rammer! Jeg elsker å ha et utvalg å velge mellom, men nevnte jeg at de alle er like ille som hverandre?
Hvis du kjenner Zend Framework, vil du ende opp med å beskrive deg selv som en Zend Framework-utvikler. du ville ikke være komfortabel med å skrive i et annet rammeverk før du hadde hatt en sjanse til å ta tak i det, og du husker sannsynligvis ikke mange av de rå PHP-funksjonene for ting hvis du ikke bruker dem ofte. Denne ideen om at vi har blitt rammespesifikke utviklere, som bare jobber på toppen av abstraksjonslag, er litt rart for PHP. Tross alt er dette språket "for å løse nettproblemet". Den er skrevet i C og er et raskt, lett språk i seg selv ... forutsatt at du ikke venter på at en stor bootstrap-prosess skal kjøre! Fra denne sammenhengen kom MicroPHP Manifesto, skrevet av en mann vi kaller Funkatron (selv om han egentlig heter Ed Finkler). Det er en rekke uttalelser som sier at det er greit å bygge en rekke interoperable små moduler, at større ikke er bedre, og at livet virkelig er for kort for Java - selv om det er skrevet i PHP.
