Innehåll
Fråga mig vilken ram jag ska använda och jag kommer antagligen ha ett grymt gammalt kvinnomoment och berätta att alla ramar är lika dåliga som varandra. Vilket är inte att säga att de alla är dåliga, exakt, men i PHP har vi ett otänkbart stort antal ramar (vanligtvis citeras som N + 1, där N är antalet PHP-utvecklare i världen), och alla var förmodligen vettiga till personen som uppfann dem.
Att ha ett urval av ramar är förmodligen bättre än att försöka använda bara ett ramverk, oavsett vad du just försökte bygga, eftersom det är det 'bästa' (oavsett mått på 'bäst'). Detta urval av ramutbud innebär att du kan välja något som uppfyller projektets behov och det kan till och med dokumenteras. Ramar på alla plattformar finns verkligen för att ge struktur, återanvändbara moduler och bibliotek, och i allmänhet undvika alla tråkiga och repetitiva uppgifter att göra med att bygga samma funktion om och om igen. Till exempel när jag bygger CMS, bör något bearbeta och validera formulärfält för mig; om jag lämnar åt mina egna enheter kanske jag missar något viktigt och jag vill hellre göra de delar av varje projekt som är annorlunda, snarare än de som är desamma varje gång!
Full-stack ramar
Full-stack-ramverk, till exempel Zend Framework, kan vara ett bra ställe att börja för en utvecklare utan mycket arkitekturupplevelse. Det ger bra struktur att hänga en ny applikation på, och det finns ett bra ”ekosystem” runt det - massor av böcker, handledning och lite rimlig dokumentation också. Om du försöker bygga en stor applikation som kommer att underhållas av många människor, är det troligt att ett populärt, omfattande ramverk är ett bra val eftersom det kommer att diktera en hel del struktur och vara välkänd och förstådd.
Att ha struktur för att hjälpa till med separation är alltid bra; tidigt i min karriär arbetade jag med några mycket juniorutvecklare och försökte lära dem MVC (Model View Controller) -mönstret, som var relativt nytt då. Vi fattade beslutet att använda Smarty i vyskiktet; dels så att formgivarna kunde arbeta med mallarna lättare, dels så att när någon kom till mitt skrivbord och sa "hur gör jag X med Smarty?" Jag kan säga "gör inte X i vyn!" (nio gånger av 10 var det svaret). Att ha ramar hjälper oss att hitta samma åtskillnad i andra delar av vår applikation. Många av dem stöder integrering mot ett malllager som Smarty, eller min nya favorit, Twig, så att du kan ta verktygen med dig vilken ram du än väljer.
Lätta på bördan
Det finns många lättare ramar än Zend Framework, till exempel jobbar jag ganska mycket med CodeIgniter. Är det lika omfattande och robust som Zend Framework? Nej, det är det inte. Men som en hjälpram för att snabbt kunna bygga en applikation är det användbart. I allmänhet kan ramar med mindre ”hjälp” -funktionalitet vara lättare att hitta runt eftersom det är mycket mer uppenbart hur bitarna går ihop. I ett okänt ramverk (för mig är det i stort sett allt), det är de automagiska bitarna som gör det svårt att arbeta med och felsöka.
Denna känsla av att vara "förlorad i en ny ram" är oundviklig och helt frustrerande. även en erfaren utvecklare känns som en nybörjare när de inte vet hur någonting fungerar. Om du verkligen har tur, har du valt ett ramverk vars IRC-kanal säger att du också är en idiot! Det är den här mycket negativa initiala upplevelsen som gör att många människor inte använder ett nytt ramverk eller antar ett i första hand, och väldigt få ramar gör ett bra jobb med att hjälpa nya användare över det första hindret.
I PHP har vi också några ramar som inte riktigt är ramar på det sätt som jag brukar använda ordet. Vi har några härliga komponentramar; samlingar av bibliotek som är utformade för att vara användbara efter vilja och för att spela snyggt tillsammans, som Zeta Components (tidigare eZ Components) och Symfony Components (har du sett deras webbplats? De vinner utmärkelsen för bästa konstverk!). Det bästa och mest undersökta av dessa är naturligtvis PHP: s egna PEAR- och PECL-erbjudanden - på något sätt glömmas de bort i denna modiga nya värld av ramar.
Microframeworks
Microframeworks är en framväxande trend inom PHP; det här är superlätta erbjudanden som bara hjälper dig att limma ihop saker snabbare. Ett bra exempel är Slim, som är väldigt snabbt och enkelt att använda, och som förstår RESTful koncept. Det bygger på idén om ”rutter”, som är webbadressmönster. Du registrerar en rutt och ger en återuppringning som ska anropas när den webbadressen begärs.
De flesta PHP-utvecklare antar ett ramverk och håller fast vid det, annars kan de använda en på jobbet och en annan för sina hobby- eller open source-projekt. Det finns liten konsensus om det "bästa" ramverket att använda så att alla bara håller sig till vad de vet och resultatet är parallell utveckling av massiva antal ramar! Jag älskar att ha ett urval att välja mellan, men nämnde jag att de alla är lika dåliga som varandra?
Om du känner till Zend Framework beskriver du dig själv som en Zend Framework-utvecklare. du skulle inte vara bekväm att skriva i ett annat ramverk förrän du hade en chans att ta itu med det och du kommer nog inte ihåg många av de råa PHP-funktionerna för saker om du inte använder dem ofta. Denna idé att vi har blivit ramspecifika utvecklare, som bara arbetar ovanpå lager av abstraktion, är lite konstigt för PHP. När allt kommer omkring är detta språket "för att lösa webbproblemet". Den är skriven i C och är ett snabbt och lätt språk i sig ... förutsatt att du inte väntar på att en stor bootstrap-process ska köras! Ur detta sammanhang framkom MicroPHP-manifestet, skrivet av en man som vi kallar Funkatron (även om han verkligen heter Ed Finkler). Det är en serie uttalanden som säger att det är okej att bygga ett antal interoperabla små moduler, att större inte är bättre och att livet verkligen är för kort för Java - även om det är skrivet i PHP.
