Hvorfor skal jeg bruke Laravel Framework

I de første dagene av den dynamiske nettet så det å skrive en webapplikasjon mye annerledes ut enn det gjør i dag. Utviklere var da ansvarlige for å skrive koden for ikke bare den unike forretningslogikken i applikasjonene våre, men også hver av komponentene som er så vanlige på tvers av nettsteder - brukergodkjenning, inngangsvalidering, databasetilgang, templering og mer.

I dag har programmerere dusinvis av applikasjonsutviklingsrammer og tusenvis av komponenter og biblioteker lett tilgjengelige. Det er en vanlig avståelse blant programmerere at når du lærer en ramme, har tre nyere (og angivelig bedre) rammer dukket opp for å erstatte det.

"Bare fordi det er der" kan være en gyldig begrunnelse for å klatre på et fjell, men det er bedre grunner til å velge å bruke et spesifikt rammeverk - eller å bruke rammer i det hele tatt. Det er verdt å stille spørsmålet: hvorfor rammer? Mer spesifikt, hvorfor Laravel?

Hvorfor bruke et rammeverk?

Det er lett å se hvorfor det er gunstig å bruke de individuelle komponentene, eller pakker, som er tilgjengelige for PHP -utviklere. Med pakker er noen andre ansvarlige for å utvikle og opprettholde et isolert stykke kode som har en veldefinert jobb, og i teorien har personen en dypere forståelse av denne enkeltkomponenten enn du har tid til å ha.

Rammer som Laravel-og Symfony, Silex, Lumen og Slim-Prepackage En samling av tredjepartskomponenter sammen med tilpassede rammer “lim” som konfigurasjonsfiler, tjenesteleverandører, foreskrevne katalogstrukturer og applikasjonsstartstraps. Så fordelen med å bruke et rammeverk generelt er at noen har tatt beslutninger ikke bare om individuelle komponenter for deg, men også om Hvordan disse komponentene skal passe sammen.

“Jeg skal bare bygge det selv”

La oss si at du starter en ny webapp uten fordel av et rammeverk. Hvor begynner du? Vel, det burde sannsynligvis rute HTTP -forespørsler, så du må nå evaluere alle HTTP -forespørsels- og svarbibliotekene som er tilgjengelige og velge en.

Deretter en ruter. Å, og du må sannsynligvis sette opp en form for Ruter konfigurasjonsfil. Hva Syntaks Skulle det bruke? Hvor skal det gå? Hva med kontrollere? Hvor bor de, og hvordan lastes de?

Vel, du sannsynligvis trenger en avhengighetsinjeksjon beholder for å løse kontrollerne og deres avhengigheter, men hvilken?

Videre, hva om du tar deg tid til å svare på alle disse spørsmålene og lykkes med å lage søknaden din - hva er innvirkningen på neste utvikler?

Hva med når du har fire slike tilpassede rammebaserte applikasjoner, eller et dusin, og du må huske hvor kontrollerne bor i hver, eller hva rutingssyntaksen er?

Konsistens og fleksibilitetsrammer tar opp dette problemet ved å gi et nøye vurdert svar på spørsmålet “Hvilken komponent skal vi bruke her?”Og sikre at de valgte komponentene fungerer godt sammen. I tillegg gir rammer konvensjoner som reduserer mengden kode en utvikler som er ny i prosjektet, må forstå - hvis du forstår hvordan ruting fungerer i ett Laravel -prosjekt, for eksempel, forstår du hvordan det fungerer i alle Laravel -prosjekter.

Når noen foreskriver å rulle dine egne rammer for hvert nye prosjekt, er det de virkelig tar til orde for muligheten til å kontrollere hva som gjør og ikke går inn på applikasjonens grunnlag.

Det betyr at de beste rammene ikke bare vil gi deg et solid fundament, men også gi deg frihet til å tilpasse til hjertets innhold.

En kort historie med nett- og PHP -rammer

En viktig del av å kunne svare på spørsmålet “Hvorfor Laravel?”Forstå Laravels historie - og forstå hva som kom før den. Før Laravels økning i popularitet var det en rekke rammer og andre bevegelser i PHP og andre nettutviklingsrom.

Ruby på skinner

David Heinemeier Hansson ga ut den første versjonen av Ruby on Rails i 2004, og det har vært vanskelig å finne et rammeverk for webapplikasjoner siden den gang som ikke har blitt påvirket av Rails på noen måte.

Rails populariserte MVC, RESTful JSON APIer, konvensjon over konfigurasjon, aktiv rekord og mange flere verktøy og konvensjoner som hadde en dyp innflytelse på måten webutviklere nærmet seg applikasjonene sine - spesielt med tanke på rask applikasjonsutviklingsutvikling.

Tilstrømningen av PHP -rammer

Det var klart for de fleste utviklere at Rails, og lignende rammer for webapplikasjon.

Cakephp var den første i 2005, og den ble snart fulgt av Symfony, Codeigniter, Zend Framework og Kohana (en kodeigniter gaffel).

Yii Ankom i 2008, og Aura og Slim i 2010. 2011 brakte FuelPhp og Laravel, som begge ikke var helt kodeigniter -offshoots, men i stedet foreslått som alternativer. Noen av disse rammene var flere Rails-Y, med fokus på databaseobjektrelasjonelle kartleggere (ORM), MVC-strukturer og andre verktøy rettet mot rask utvikling. Andre, som Symfony og Zend, fokuserte mer på bedriftsdesignmønstre og netthandel.

Det gode og det dårlige av kodignator

CakePHP og Codeigniter var de to tidlige PHP -rammene som var mest åpne om hvor mye inspirasjonen deres ble hentet fra skinner. Codeigniter steg raskt til berømmelse, og i 2010 var uten tvil den mest populære av de uavhengige PHP -rammene.

CodeIgniter var enkel, enkel å bruke, og skrøt av fantastisk dokumentasjon og et sterkt samfunn. Men bruken av moderne teknologi og mønstre avanserte sakte, og etter hvert.

I motsetning til mange andre rammer, ble Codeigniter administrert av et selskap, og de var trege med å ta igjen PHP 5.3s nyere funksjoner som navneområder og trekkene til GitHub og senere komponist. Det var i 2010 at det Taylor Otwell, Laravels skaper, ble misfornøyd med Codeigniter til at han satte i gang for å skrive sine egne rammer.

Laravel 1, 2 og 3

Den første betaen til Laravel 1 ble utgitt i juni 2011, og den ble skrevet helt fra bunnen av. Den inneholdt en tilpasset ORM (veltalende); Lukkingsbasert ruting (inspirert av Ruby Sinatra); et modulsystem for utvidelse; og hjelpere for skjemaer, validering, autentisering og mer.

Senere kom Laravel 4 og Laravel 5 og endret hele spillet.

Hva er så spesielt med Laravel?

Så hva er det som skiller Laravel fra hverandre? Hvorfor er det verdt å ha mer enn ett PHP -ramme når som helst? De bruker alle komponenter fra Symfony uansett, ikke sant? La oss snakke litt om hva som får Laravel til å "krysse av.”

Filosofien om Laravel

Du trenger bare å lese gjennom Laravel markedsføringsmateriell og readmes for å begynne å se verdiene. Taylor bruker lysrelaterte ord som "Illuminate" og "Spark.

Og så er det disse: “Håndverkere?'"Elegant?'Også disse: "frisk luftpust." "Ny start.”Og til slutt:“ Rask.”“ Varphastighet.”De to sterkest kommuniserte verdiene i rammen er å øke utviklerhastigheten og utviklerens lykke.

Taylor har beskrevet 'håndverkeren' språket som med vilje kontrasterer mot mer utilitaristiske verdier. Du kan se genesen til denne typen tenkning i hans spørsmål om 2011 om Stackexchange (http: // bit.ly/2dt5kms) der han uttalte, “Noen ganger bruker jeg latterlige mengder tid (timer) som gjør at koden ser pen ut” - Bare for en bedre opplevelse av å se på selve koden.

Og han har ofte snakket om verdien av å gjøre det enklere og raskere for utviklere å ta ideene sine til å bli utført, bli kvitt unødvendige barrierer for å lage gode produkter. Laravel handler i kjernen om å utstyre og muliggjøre utviklere. Målet er å gi klar, enkel og vakker kode og funksjoner som hjelper utviklere raskt å lære, starte og utvikle og skrive kode som er enkel, tydelig og vil vare.

Konseptet med å målrette utviklere er klart på tvers av Laravel -materialer. “Happy Developers Make the Best Code” er skrevet i dokumentasjonen.

“Developer Happiness from Download to Deploy” var det uoffisielle slagordet en stund. Selvfølgelig vil ethvert verktøy eller rammeverk si at det ønsker at utviklere skal være lykkelige. Men å ha utviklerens lykke som en primær bekymring, snarere enn sekundær, har hatt stor innvirkning på Laravels stil og beslutningstaking fremgang. Der andre rammer kan målrette arkitektonisk renhet som sitt primære mål, eller kompatibilitet med målene og verdiene til bedriftsutviklingsteam, er Laravels hovedfokus på å betjene den enkelte utvikler.

Hvordan Laravel oppnår utviklerens lykke

Bare det å si at du vil gjøre utviklere lykkelige er en ting. Å gjøre det er en annen, og det krever at du stiller spørsmål ved hva som i en ramme mest sannsynlig vil gjøre utviklere ulykkelige og hva som mest sannsynlig vil gjøre dem lykkelige. Det er noen få måter Laravel prøver å gjøre utviklernes liv enklere.

For det første er Laravel et raskt rammeverk for applikasjonsutvikling. Det betyr at den fokuserer på en grunt (enkel) læringskurve og på å minimere trinnene mellom å starte en ny app og publisere den. Alle de vanligste oppgavene i å bygge webapplikasjoner, fra databaseinteraksjoner til autentisering til køer til e -post til hurtigbufring, blir gjort enklere av komponentene laravel gir.

Men Laravels komponenter er ikke bare bra på egen hånd; De gir et konsekvent API og forutsigbare strukturer over hele rammen. Det betyr at når du prøver noe nytt i Laravel, vil du mer enn sannsynlig ende opp med å si: “… og det fungerer bare?'

Dette ender ikke på selve rammen, heller. Laravel gir et helt økosystem av verktøy for å bygge og lansere applikasjoner. Du har husmann.Og det er en pakke med tilleggspakker:

• Kasserer - for betalinger og abonnement
• Echo - For WebSockets
• Speider - for søk
• Pass - for API -godkjenning
• Sosialitet - for sosial pålogging
• Spark - å bootstrap dine SaaS.

Laravel prøver å ta det repeterende arbeidet ut av utviklernes jobber slik at de kan gjøre noe unikt.

“Utdrag fra - Laravel Up & Running Book”