Velg riktig PHP-rammeverk

Innhold

• Robuste nettsteder
• 01. Hva er egentlig et PHP-rammeverk?
• 02. Hvordan kan det hjelpe?
• 03. Konvensjon om konfigurasjon
• 04. Vis separasjon
• 05. Databasestøtte
• 06. Fellesskap
• 07. Dokumentasjon
• 08. Ytterligere PHP rammefunksjoner
• 09. Hovedutfordrere
• 10. Velge rammeverk
• 11. Andre teknologier
• 12. Konklusjon
• Likte dette? Les disse!

Et PHP-rammeverk gir et grunnlag der utviklerkoden kan ordnes pent. Dokumentasjon, vanlige problemer, løsninger, tips og råd kan deles online på en åpen kildekode måte.

I dagene før nettrammer var det vanlig å se nettsteder skrevet på en proprietær måte. Ulike kodere vil bruke sitt eget arsenal av teknikker og metoder for å ordne koden og utforme arkitekturen. Dette vil skape en rekke problemer: mangel på dokumentasjon, komplekse proprietære rammer - eller vanlig tilfelle av 'hva skjer når en programmerer forlater?'

Utviklere prøvde ofte å løse problemet med å organisere kode ved å følge prosessen med 'separasjon av bekymringer', i utgangspunktet bryte større problemer ned i mindre og markere tydelige arbeidsgrenser mellom kodeseksjoner.

Malmotorer ga et annet nyttig verktøy for å hjelpe webapputvikling. Smarty Template Engine er et langvarig, populært bibliotek som gjør det enkelt å skille mellom de to områdene av kode nettutviklere ofte håndterer: generering av innhold (også kjent som forretningslogikken) og hvordan det vises (presentasjonsmarkering eller visning).

Robuste nettsteder

Frameworks ble virkelig tatt i bruk i 2004, da de tilbød seg som en omfattende løsning for å bygge robuste nettsteder. De fleste av de populære PHP-rammene er hovedsakelig basert på designmetoden som kalles modell-view-controller eller kort sagt MVC. Det er sannsynligvis ikke tilfeldig at det velkjente Ruby on Rails MVC-rammeverket ble lansert rundt midten av 2004; dette vil utvilsomt ha vært en inspirasjon for mange andre PHP-rammer.

En av de første PHP-rammene på scenen var Mojavi Project, dessverre ikke lenger aktiv. I dag er det imidlertid mange PHP-rammer som kjemper for vår oppmerksomhet. I denne artikkelen vil vi dekke de fire store PHP-rammene som nå ofte brukes i bransjen: CakePHP, CodeIgniter, Symphony og Zend.

01. Hva er egentlig et PHP-rammeverk?

Så hva er et PHP-rammeverk? I hovedsak er det et sett med PHP-klasser og funksjoner som utviklere holder seg til når de utvikler et nettsted. MVC-paradigmet kan sees på som en utvidelse av malmotorer. Her er en rask forklaring:

• Modell: Modellen inneholder logikkoden for serverens virksomhet. Dette innebærer vanligvis lesing og skriving til en database i tillegg til noe for- eller etterbehandling. For eksempel: ‘En bruker legger inn en kommentar, men før vi setter den inn i databasen, må vi gjøre en søppelpostkontroll med akismet.com; hvis det går, kan vi gjøre innsatsen. ’
• Utsikt: Dette er hvor du presenterer utdataene for brukeren i et bestemt format, ofte HTML-markering, selv om det kan være JSON- eller XML-format. For eksempel: ‘Vi må vise alle kommentarene til et forumemne, modellen henter alle kommentarene og blir deretter lest og formatert av visningen.’
• Kontroller: Kontrolleren er egentlig lederen. Den fanger først URL-en, og kaller deretter de riktige modellene og visningene før den presenteres for nettleseren, mobilenheten eller en API-innringer. For eksempel: ‘Ved å vise alle kommentarene til et emne, foretar kontrolleren selve anropet til modellen og sender deretter modelldataene til visningen, som deretter genererer HTML-utdata. Denne genererte visningen blir deretter vist til den anropende nettleseren av kontrolleren. ’

Et PHP-rammeverk gir deg en veldefinert kodemal der du må plassere visse typer koder. Følgende ultra enkle PHP-kode vil gi koderen et innblikk i hvordan MVC fungerer generelt. Det viser gjeldende vær der du er!

? php
// Været "kontroller"
funksjon controller_weather () {
$ type = modell_vær ();
ekko view_weather ($ type);
}
// Få gjeldende data / vær, "modellen"
funksjon modell_vær ()
// få data
$ status = ’Se ut av vinduet!’;
returnere $ status;
}
// Generer HTML-presentasjon, "visningen"
funksjon view_weather ($ type) {
// design og layout skal være her
returner ‘b> Været der du er: / b>
’. $ Type;
}
// fange opp URL og ring den aktuelle kontrolleren
hvis (strstr ($ _SERVER [’REQUEST_URI’], ’/ weather /’
) ) {
controller_weather ();
}
?> var13 ->

En vanlig feil er å blande kode mellom kontroller og modell. Bedriftskode bør ideelt sett alle være på ett sted: i modellen, eller faktisk et tredjepartsbibliotek. Et godt spørsmål å stille deg selv er, ‘ville andre kontrollere brukt denne logikken; er det et generisk kodestykke? ’Hvis ja, bør det høre hjemme det ene stedet, modellen er den vanligste.

Det er fremdeles en viss forvirring om hvor forretningslogikk skal plasseres, i kontrollere eller modeller. Bare Google ‘fat models skinny controllers’. Mye av problemet stammer fra det faktum at ‘forretningslogikk’ er et uklart begrep.

En annen god måte å ha et rent skille mellom forretningslogikk og visning er å utvikle et API for å legge til rette for integrasjon til andre systemer. Dette tvinger mer eller mindre et webteam til å bygge et robust system, siden den samme forretningslogikken må kunne tilpasses forskjellige scenarier. I tillegg må hensynet til dette være på plass helt fra starten av et prosjekt.

Visningen er mye lettere å avgrense: du kan bare ha syntaks for programmeringsvisning i visningen. Kontrollere og modeller skal aldri inneholde presentasjonssyntaks, for eksempel br />. Du vil være i store problemer hvis du gjør det!

02. Hvordan kan det hjelpe?

Å bruke et PHP-rammeverk er kanskje ikke svaret på hvert prosjekt. Du må se på miljøet ditt og vurdere hvor godt et PHP-rammeverk kan passe inn. Her er noen fordeler og ulemper ved å bruke rammer:

Fordeler

• PHP-rammeverk kan brukes som en rask applikasjonsutviklingsmetode, slik at raske prototyper kan utvikles.
• Siden hvert prosjekt er basert på en lignende struktur, tillater det en raskere utviklingssyklus.
• Utviklere kan enkelt hoppe fra prosjekt til prosjekt uten å bekymre seg for mye om kodens struktur.
• Spiller godt med Agile programvareutvikling.
• Den underliggende koden vil endres sjeldnere, noe som resulterer i et mer stabilt nettsted.

Ulemper

• Noen rammer har en bratt læringskurve.
• Det kan være vanskelig å finne utviklere med erfaring fra et bestemt rammeverk.
• Ikke alle rammer er feilfrie
• Hackere kan utnytte svakheter i rammene.
• Ulike rammers fortolkninger og støttebiblioteker av MVC-prinsippet kan variere.

PHP-rammer og rammer generelt er hovedsakelig innenfor utviklerens domene. Imidlertid har andre parter i et webprosjekt forskjellige behov når det gjelder rammer:

• Ledere / eiere: De tre forskjellige domenene til modell-visningskontroller innenfor et rammeverk gir ledere en måte å dele oppgaver i håndterbare biter. For eksempel trenger en utvikler som arbeider innenfor produktmodellen ikke bekymre seg for hvordan den brukes eksternt. Den eksterne presentasjonen blir behandlet av View. Et rammeverk muliggjør lettere parallell utvikling. Agil utvikling er en prosjektledelsesmetode som passer godt med rammer. Med mange verktøy tilgjengelig i praktisk talt alle rammer og en ren struktur kan ledere forstå, er rask utvikling og snuoperasjoner normen.
• Designere: Den visuelle representasjonen vil alltid være en vanskelig oppgave å slå sammen til kode. Å bruke et MVC-rammeverk hjelper, men oppgaven er fortsatt kjedelig og vanskelig. Utviklere må dele et design i de individuelle komponentene og dele det i de riktige visningene. Dette er hvor CSS-rammer noen ganger kan hjelpe.

03. Konvensjon om konfigurasjon

For at rammer skal håndtere mange scenarier, er konfigurasjonsinnstilling et viktig område. De fleste rammeverk velger "convention over configuration" designløsningen. For eksempel hvis PHP-klassen for en modell kalles modellstudenter, skal databasetabellen navngis studenter og PHP-klassen for den tilsvarende visningen skal kalles view_studenter. Dette senker kompleksiteten i konfigurasjonsinnstillingene, slik det fremgår av forrige PHP-væreksempel.

Konfigurasjonsfiler gir mer fleksibilitet og kontroll; ulempen er at de kan legge til kompleksitet i forhold til konvensjon over konfigurasjon.

Følgende er et konfigurasjonskodebit fra Symfonys rutingsfil:

# app / config / routing.yml
Hallo:
mønster: / hallo / {name}
standardinnstillinger: {_kontroller:
AcmeHelloBundle: Hei: indeks}

Den korresponderende koden er ganske enkelt et 'hallo verden'-skript: hvis nettadressen for eksempel er eksempel.com/hello/Bob, så er utgangen ‘Hello Bob’. Utdraget av syntaksen ovenfor samsvarer med URL-en med riktig styrekode.

04. Vis separasjon

Et av de største problemene som bruken av MVC-rammer løser, er å skille forretningslogikk fra datautdata.

Å blande litt kode i presentasjonslogikken er uunngåelig når du bruker et PHP-rammeverk. Du vil imidlertid holde enhver presentasjonsmarkering utenfor kontrolleren - og enda viktigere, modellen. Så i vårt enkle væreksempel, hvis vi bestemmer oss for å legge til den dristige HTML-koden b>, vil det bli ansett som dårlig praksis fordi det sannsynligvis vil forårsake problemer hvis presentasjonen er i JSON eller XML.

function model_weather () {
// Dette er dårlig!
// Ingen presentasjonsmarkering tillatt i modellen !!
// Fix eller annet!
$ status = ’b> Se ut av vinduet! /
b> ’;
returnere $ status;
}

05. Databasestøtte

Webapper bruker oftest en database for å lagre permanente brukerdata. Alle de fire store PHP-rammene har god støtte for MySQL og andre vanlige databasedrivere som Oracle og MS Server. Det er en relatert programvarekomponent kalt object-relational mapping (ORM), som noen PHP-rammer bruker. Spesielt Symfony bruker tung bruk av Doctrine, en tredjeparts ORM som også kan brukes i andre PHP-rammer. ORM har som mål å forenkle databasekoden i et webprosjekt.

06. Fellesskap

Alle de store PHP-rammene vi diskuterer har støtte fra samfunnet; CodeIgniter er spesielt aktiv. Vær oppmerksom på antall opplæringsprogrammer for hvert PHP-rammeverk skrevet av bloggere: en sårt tiltrengt ressurs for å hjelpe utviklere med å forstå et PHP-rammeverk. Bemerkelsesverdig faktum: Symfony gjorde en større versjonsoppgradering i 2011. Kunnskap om den nye versjonen 2 er kanskje ikke relevant; versjon 2 er imidlertid en stor endring i et bevist rammeverk.

07. Dokumentasjon

Dokumentasjon er viktig som referansepunkt. Det burde ikke være behov for å grave gjennom kildekoden for å se hvordan ting skal fungere, selv om det er en vanlig forekomst. Dokumentasjon bør ha gode eksempler for hver funksjon. Dessuten bør et godt PHP-rammeverk også ha en rekke bøker, forum og videoopplæringsprogrammer.

08. Ytterligere PHP rammefunksjoner

• Hjelperfunksjoner: Dette er ofte vanlige PHP-funksjoner som bare utfører en oppgave, for eksempel e-postvalidering.
• Bufring: Dette blir viktigere ettersom mer innhold er tilgjengelig på flere forskjellige måter. Alle PHP-rammer har varierende grad av hurtigbufring. Mange webeiere velger også tredjepartsverktøy som blekksprut.
• Enhetstesting: Dette muliggjør automatisk testing av kode i appen din. For store prosjekter bør du prøve å legge til noen enhetstesting. Alle gjennomgåtte PHP-rammeverk har enten sine egne enhetstestmetoder eller bruker PHPUnit, som stort sett er de facto PHP-testpakken.
• Formgenerering: Her kan PHP-rammer virkelig skinne. Skjemaer er så utbredte i webapper at de fleste rammer har genererings- eller valideringsfunksjoner for å hjelpe utviklere med å legge til webskjemaer.
• Økt: Øktefunksjonene i PHP fungerer allerede ganske bra. De fleste PHP-rammer legger til funksjoner på toppen av den eksisterende PHP-økten. Spesielt Zend har gode øktkontrollfunksjoner.
• Mal: Dette refererer til hvordan kode er organisert i en visning. Den prøver å svare på spørsmålet, ‘hva er den beste måten å organisere kode i visningen?’. Smarty Template var en tidlig løsning før MVC-rammer. I sammenheng med denne artikkelen er Symfony det eneste rammeverket som bruker en malprogramvare, kalt Twig. Det ligner veldig på Smarty Template og ble utviklet av samme selskap som Symfony.
• Utvide / tredjepartsmodul: Tredjeparts plugin-moduler og temaer har vært drivkraften bak utviklingsplattformer som WordPress og Drupal. Noen MVC-rammer har som mål å gjøre det samme; stort sett alle har rudimentære tredjepartsutvidelser eller plugin-moduler, med unntak av CakePHP. Rammeverk må gjøre mer på dette området.
• ACL: Adgangskontroll og påloggingsadministrasjon er en vanlig funksjon i mange nettapper. Alle rammene gir forskjellige nivåer av funksjoner knyttet til det som ofte kalles tilgangskontrollister (ACL). CodeIgniter er det eneste rammeverket der du trenger å søke på nettet etter tredjeparts ACL-plugin-moduler.

09. Hovedutfordrere

Det er godt over 20 forskjellige open source PHP-rammer; dette fører ofte til et alvorlig tilfelle av hjernefrysning. Men de siste årene har de fire store rammene CakePHP, CodeIgniter, Symphony og Zend gradvis kommet til å dominere.

Dette er nede på lang levetid, samfunnsstøtte og dokumentasjonshjelp. Funksjoner brukes ikke fordi de for det meste gjør lignende ting, og hvis et rammeverk mangler en funksjon, er det sannsynlig at en tredjeparts plugin-modul vil være tilgjengelig. Hvordan en hammer er bedre enn en annen, handler ofte om personlig filosofi, tidligere erfaring eller nåværende arbeidsmiljø.

Av de fire rammene hører CodeIgniter og CakePHP veldig sammen, med CodeIgniter som er enklest å hente. Dette etterfølges av Zend og Symfony, fordi de er veldig like. Symfony har den bratteste læringskurven i forhold til Zend, på grunn av en større mengde kunnskap som må hentes.

1 CakePHP
Fordeler Aktivt fellesskap; Cake Bakery (bakeri. Cakephp.org)
Ulemper Kake har veldig spesifikke måter å gjøre ting på

Dette rammeverket henter inspirasjon fra Ruby on Rails og tilhører veldig mye KISS (hold det enkelt dumt) leiren. Dens rammestruktur er lett å forstå. Det er mapper for kontrollere, modeller og visninger. De fleste webapps vil ha det meste av koden i disse tre mappetypene.

Høydepunktet med CakePHP er Cake Bakery der tredjepartsutviklere kan legge til sin egen kode og dele den med samfunnet. CakePHP er en god mellomvei, ikke så enkel som CodeIgniter, men ikke så kompleks som Zend eller Symfony.

CakePHP har ikke tillegg som ORM eller en malmotor. Av de fire rammene er dette den eneste som ikke har bedriftens støtte - men det kan sees på som et pluss poeng.

2 CodeIgniter
Fordeler Hastighet; veldig lett; stort aktivt fellesskap, god dokumentasjon
Ulemper Kan tillate for mye frihet i koding

Opprettet av EllisLab i Oregon og utgitt kort tid etter CakePHP, i 2006, er dette flott i prosjekter der en best of breed-tilnærming er favorisert. Du kan legge til annen tredjepartsprogramvare uten å føle deg vektet, og som CakePHP og Zend har den en tydelig MVC-mappestruktur som du kan følge. CodeIgniter gir også utviklere større takhøyde for å løse problemer i henhold til deres tenkning, i motsetning til Zend eller Symfony, der du trenger å tenke i forhold til den individuelle metoden.

3 Symfony
Fordeler ORM; har sin egen malmotor
Ulemper Bratt læringskurve

Symfony, opprettet av det franske byrået SensioLabs, føles definitivt annerledes. Den fremmer bruk av ORM, et pluss for tungt databasearbeid, og bruker sin egen Twig malmotor, også opprettet av SensioLabs.

For å få en følelse, gå til symfony.com, versjon 2-siden. Ikke bli forvirret med versjon 1-siden, symfony-project.org; versjon 2 er den å lære!

Det er ikke en åpenbar MVC-terminologi innen Symfony, selv om den gjør omtrent det samme som de andre rammene. Den har et unikt konsept som kalles bunter, samlinger av relatert kode eller filer som hjelper til med å skille funksjoner for webapper. Som Zend spiller kodegenerering en viktig rolle i Symfony.

Dette er det vanskeligste rammeverket å forstå, men med god samfunnsstøtte er hjelpen aldri langt unna. Modellstrukturen er forskjellig fra mange andre rammer: den fremmer doktrine som inngangspunkt for forretningslogikkmodellkoden.

4 Zend
Fordeler God bedriftsprogramvare med lang levetid
Ulemper Designmønsterkonsepter tar tid å forstå

Opprettet av Zend, firmaet bak PHP-motoren, var det åpenbart at dette rammeverket ville bli tatt på alvor. Zend har funksjonene til en robust programvare i bedriftsstil samt relaterte kommersielle produkter som en kommersiell webserver, support og egen IDE. I kombinasjon gjør disse det til en kraftig måte å utvikle webapper på.

Zend ligner CodeIgniter og CakePHP, men tung dokumentasjon basert på designmønsterkonsepter kan gjøre det vanskelig å komme i gang med.

Zend er sannsynligvis det mest etterspurte rammeverket når man ser på PHP-relaterte stillingsbeskrivelser, og har ganske mange gode funksjoner innenfor seg. Lucene-søkefunksjonen bringer nettsøk av kommersiell karakter til en app; andre høydepunkter inkluderer skjemaoppretting, datafiltrering og internasjonalisering. Men Zend er mye mer enn et PHP-rammeverk; du drar nytte av støtte, opplæring, sertifisering og relaterte produkter.

10. Velge rammeverk

Å velge rammeverk kan i stor grad avhenge av prosjektforhold, og som med ethvert verktøy er det et personlig filosofisk valg. En enmannsbyrå vil kanskje ha en rask behandling med en kort læringskurve. et stort firma foretrekker kanskje robust programvare som har følelsen av Java - kriteriene Zend vil oppfylle.

Lang levetid er en viktig faktor. Det er nært knyttet til dokumentasjon; rammer med lang historie har et større kunnskapsbasseng. Kostnader kan også være et problem: rammer med brattere læringskurver, som Zend eller Symfony, vil kreve dyktige kodere - noe som alltid betyr høyere lønn. Kommersiell støtte er ofte nødvendig for store prosjekter; Zend eller Symfony er godt plassert til å ta stedet.

Som nevnt ovenfor, hvis du søker en karriere innen PHP-koding, er Zend de viktigste rammeverkene bedt om. Dette kan også drives av det faktum at e-handelsplattformen Magento bruker Zend som sin underliggende struktur.

For skreddersydde apper er det ofte vanskelig å tenke hvorfor du ikke bruker et rammeverk. Det kan imidlertid være noen få unntak:

• Du vil at nettstedet skal dra nytte av skinning / temaer, slik at du enkelt kan utvikle generiske nettsteder, i så fall er WordPress en god kandidat å bruke.
• Du vil kanskje ikke ha bryet med å håndtere tredjepartsfeil i rammer. Det kan også være for mye uønsket automagisk oppførsel.

Tabellen nedenfor viser noen av funksjonene hver av de fire store rammene har for å hjelpe deg med å bestemme hvilken som er den rette for prosjektet ditt:

Rammeverk generelt gir en solid forankring i å lage skreddersydde webapper fra bunnen av. Imidlertid kan PHP-rammer ofte bli forvekslet med CMS-systemer som Joomla, WordPress eller Drupal; de gir en ferdig laget plattform for innholdsadministrasjon som du også kan legge til skreddersydde funksjoner til.

Folk spør ofte om å bytte fra ett rammeverk til et annet er en enkel oppgave. Kort sagt, migrering fra ett rammeverk eller faktisk fra et CMS-system tilsvarer en komplett omskriving av nettstedet. Selv om de alle bruker en MVC-arkitektur, er hver rammes fortolkning og filosofi vesentlig forskjellige.

11. Andre teknologier

Alle PHP-rammer bør aldri være frittstående. Integrering med tredjeparts programvare må tas i betraktning. Det er rettferdig å si at jo større PHP-rammeverket er, er det vanskeligere å gjøre det.

Å innlemme JavaScript-biblioteker / rammeverk er generelt greit; det involverer mer eller mindre frontend. Alle PHP-rammene har hjelpefunksjoner for å inkludere JavaScript og CSS-filer. I den andre enden av skalaen kan du bare inkludere biblioteket som en rett skript> tag i HTML-koden.

PHP-rammer er også utstyrt for å håndtere mange av de vanlige sikkerhetsproblemene, for eksempel XSS (tilgangssårbarhet), XSRF (laste inn en ondsinnet side) og SQL-injeksjon (stjele data). Og når det gjelder SEO, har alle rammene strukturer innebygd for å håndtere krav som URL-omskriving. Merk at hastighet er en faktor for SEO, og størrelsen på rammeverket må vurderes.

Til slutt, når du tenker på cloud computing / hosting, bør store rammer som Zend eller Symfony tas med når du kjøper servere.

12. Konklusjon

I de fleste tilfeller gir rammene en hjelpende hånd til ethvert prosjekt. Men som med ethvert verktøy, avhenger av omstendighetene hvor mye de kan hjelpe veldig mye.

Hvis nettstedet ditt involverer mer innhold, kan Drupal eller WordPress passe bedre. Hvis du bygger neste Twitter for å lansere ASAP, vil CodeIgniter eller CakePHP være gode valg. Hvis miljøet ditt er bedriftsmessig, kan det hende Zend eller Symfony passer best.

Til slutt - hvis du føler at du trenger å lage et skreddersydd PHP-rammeverk, kan du knekke: det er faktisk ganske morsomt!

Denne artikkelen dukket først opp i .net - verdens mest solgte magasin for webdesignere og utviklere.

Kai Chan er frilans webutvikler, har over 16 års erfaring med å lage webapper for bedriftsmerker og elsker nye oppstartsideer

Likte dette? Les disse!

• 50 fantastiske eksempler på HTML5
• Hvordan lage en app
• De beste gratis nettfonter for designere