Share
Etter hvert som PHP-applikasjoner blir mer og mer komplekse, kan det være lett å ende opp med et sammenbrudd av kode som gjør vedlikehold nesten umulig. Bruk av begrepet tiered applikasjoner kan bidra til å lindre noe av vanskeligheten ved å opprettholde komplekse applikasjoner.
Tiered programmering er praksis for å holde forskjellige komponenter, ideer eller språk skilt fra hverandre.
I front-end-utvikling vil tiered markup bruke eksterne stilark og JavaScript.
Ved å koble til en CSS-fil i stedet for å legge inn stiler i HTML-oppslaget, blir det lettere å endre
formatering av websidene dine fordi nå er all stylinginformasjon lagret på ett sted, skilt
fra dokumentets oppføring. Og flere HTML-sider kan trekke i nøyaktig samme CSS-fil, hele nettstedet ditt
kan oppdateres stilmessig ved ganske enkelt å endre en linje med CSS.
I back-end-utvikling gjelder de samme reglene, men vi har å gjøre med ulike komponenter. I bred grad er vi
ser på tre nivåer: database (lagring og henting av data), Virksomhet
(behandling og håndtering av data), og Presentasjon (hvordan data vises) tiers.
Det kan ikke være umiddelbart opplagt, men å skille søknadene dine til en tiered struktur vil ha en stor
påvirke kodenes evne til å endre seg i fremtiden. Hvis du for eksempel har et bloggingssystem satt opp, og
det blir nødvendig å lage en RSS-feed for bloggen, en riktig tiered søknad vil tillate deg å enkelt
sette opp en RSS-mal, og ring deretter databasen og forretningsfunksjonene som du allerede har skrevet.
På motsatt side, hvis klienten plutselig bestemte seg for at PostgreSQL var et bedre valg for organisasjonen
enn MySQL, trenger du bare å omskrive databasens funksjoner, alt uten å berøre virksomheten eller
presentasjonslogikk av søknaden.
Når det gjelder gjenbruk, kan du ha flere databasefunksjoner (som støtter MySQL, PostgreSQL og
Oracle, for eksempel), som lett kunne slippes inn i nye utrullinger av søknaden din ved hjelp av bare noen få
linjer med kode på ett sted, i stedet for å redigere flere linjer av koden din på tvers av flere funksjoner.
For å starte, la oss ta en ganske enkel oppgave - trekke tittel og kroppstekst av en oppføring ut av en database,
lage en forkortet versjon av oppføringen, og plassere dataene i HTML-oppsummering - og gå om det i
helt feil vei. I den følgende koden skriver vi en funksjon for å utføre alle våre
oppgaver:
Accentsconagua
funksjon displayEntry () $ entryDisp = NULL; // Hent informasjonen fra databasen $ sql = "SELECT tittel, oppføring FRA oppføringer WHERE page =" blog ""; $ r = mysql_query ($ sql) eller dø (mysql_error ()); mens ($ entry = mysql_fetch_assoc ($ r)) $ title = $ entry ['title']; $ text = $ entry ['entry']; // Opprett tekstforhåndsvisning $ textArray = eksplodere (", $ tekst); $ forhåndsvisning = NULL; for ($ i = 0; $ i<24; $i++) $preview .= $textArray[$i] ."; $preview .= $textArray[24] . '… '; // Format the entries $entryDisp .= << $ title $ forhåndsvisning
ENTRY_DISPLAY; returner $ entryDisp; Denne koden utfører HTML-merking langs disse linjene:
Entry One
Dette er den forkortede beskrivelsen av oppføring nummer ett. Den viser de første 25 ordene i oppføringen, og deretter slår av med en ellipsis ...
Oppføring to
Dette er den forkortede beskrivelsen av oppføring nummer to. Den viser de første 25 ordene i oppføringen, og deretter slår av med en ellipsis ...
Selv om dette kan virke logisk, er det faktisk egentlig uønsket. La oss gå over hva som gjør dette
kode en mindre enn optimal tilnærming.
Dårlig lesbarhet-Denne koden er fortynnet. Dens formål, men dokumentert i kommentarene
(slags), er vanskelig å skille. Hvis du skrev dette, kom tilbake til det om seks måneder, ville det ikke være umiddelbart
fjern hva som skjedde, noe som betyr at noen sekunder / minutter går bort, og prøver å tolke din egen kode.
For begrenset i fokus-Denne funksjonen er forkrøpet av dens spesifisitet: databasespørsmålet virker bare for en type oppføring;
Forhåndsvisning av tekstforhåndsvisning er hardkodet i funksjonen; formateringen er spesifikk for typen oppføring
blir vist. For å skape en litt annen implementering av denne funksjonaliteten, ville vi bli tvunget til
lag en annen funksjon som så nesten nøyaktig det samme ut, selv om alt vi trengte å endre var antall
ord i tekstforhåndsvisning.
Mangel på skalerbarhet-Dette er ganske nært knyttet til ideen om å være for smal i fokus; hvis vi vil legge til mer funksjonalitet (for eksempel
som en lenke eller et bilde), blir vår funksjon større og vanskeligere å håndtere. Og hva om vi vil legge til
forhold som påvirker hvordan en oppføring vises? Det er lett å se hvordan programmering som dette tillater kode til
bli raskt viltvoksende og uhåndterlig.
Dette er feiende problemet som forårsaker alle de nevnte problemene.
Ved å kombinere alle tre av vår logikk
typer, vi ender med en smal, rotete, vanskelig å administrere, nesten umulig å gjenbruke tangle av kode.
Tenk deg et program hvor hver type skjerm (RSS-feed, oppføringsvisning, full oppføringsskjerm, etc.) ble bygget med
en funksjon som den ovenfor, med databasetilgang, forretningslogikk og presentasjonslogikk alle skrevet sammen.
Forestill deg nå at det er ni sider på nettstedet, som alle har sin egen inngangsvisning og forhåndsvisningsfunksjoner.
Selv om vi antar at søknaden er veldig enkel og at det bare er to funksjoner per side side, er vi fortsatt
ser på nesten tjue funksjoner som må oppdateres hvis endringer blir nødvendige.
For å forbedre koden ovenfor, sprer vi våre ulike typer logikk over flere funksjoner. Hvis gjort riktig, vi
bør ende med et sett med svært gjenbrukbare, lettforståtte funksjoner som stabler for å utføre en rekke oppgaver.
For å komme i gang, planlegger vi den nødvendige funksjonaliteten for å få en bedre ide om
hvordan det skal bygges
Som du kan se, vår plan identifiserer tydelig en database, forretnings- og presentasjonsnivå. Vi kan nå
skrive funksjoner for å oppfylle hvert av disse trinnene relativt enkelt.
For å få informasjon fra databasen, skal vi skrive en veldig enkel funksjon. Å oppmuntre til god koding
praksis, jeg skal bruke mysqli forlengelsen, men
Jeg skal ikke fokusere på hvordan det fungerer. Hvis du ikke bruker det allerede, vil jeg oppfordre deg til å utforske mysqli eller a
lignende utvidelse (dvs. PDO) for å sikre dine MySQL-spørringer mot
injeksjonsangrep.
Så la oss hoppe rett inn i koden:
funksjon getDataFromDB ($ side) / * * Koble til en MySQL-server * / $ mysqli = new mysqli ('localhost', 'bruker', 'passord', 'verden'); hvis (mysqli_connect_errno ()) printf ("Koble mislyktes:% s \ n", mysqli_connect_error ()); exit; / * * Opprett en forberedt setning for å trekke alle oppføringer fra en side * / hvis ($ stmt = $ mysqli-> forberede ('VELG tittel, oppføring FRA oppføringer WHERE page =?')) / * * Opprett en multi- dimensjonal array for å lagre * informasjonen fra hver oppføring * / $ entries = array (); / * * Bind passordet til forespørselen, hent dataene, og sett * inn i array $ -oppføringene for senere bruk * / $ stmt-> bind_param ("s", $ side); $ Stmt-> utføre (); $ stmt-> bind_result ($ title, $ entry); mens ($ stmt-> hente ()) $ oppføringer [] = array ('title' => $ title, 'entry' => $ entry); / * * Ødelegg resultatsettet og frigjør minnet som brukes til det * / $ stmt-> close (); / * * Lukk tilkoblingen * / $ mysqli-> close (); / * * Return array * / return $ entries; Hvis du bryter ned hva denne funksjonen gjør, ber vi bokstavelig talt bare
To kolonner (tittel og oppføring) fra vårt bord (oppføringer), og lagrer hver oppføring
i en multidimensjonal assosiativ array, som er returverdien til
funksjon. Vi sender en parameter, $ side, slik at vi kan finne ut hvilken side vi er
gripende informasjon for. Ved å gjøre det har vi nå opprettet en funksjon som vil fungere
for hver side av nettstedet vårt (forutsatt at de alle har et "tittel" og "oppføring" -felt).
Legg merke til at vår funksjon ikke gjør noe for håndtak dataen; det virker bare
som kurir, tar tak i informasjonen vi ber om og sender den videre til hva som helst
kommer neste. Dette er viktig, fordi hvis det gjorde noe mer, ville vi være i
rike av forretningslogikk.
Det korte svaret er at det tillater database
abstraksjon, noe som i hovedsak betyr at dataene kan flyttes fra MySQL
inn i et annet databaseformat, for eksempel PostgreSQL eller Oracle, alt uten
Endring av datahåndteringsfunksjonene (virksomhetsnivå), siden produksjonen ville
fortsatt ganske enkelt være en multidimensjonal assosiativ array som inneholder oppføringer med a
tittel og oppføringskolonne, uansett hvilken type database vi bruker.
Med dataene lastet inn i vårt utvalg, kan vi begynne å behandle informasjonen til
passer for våre formål. I dette eksemplet prøver vi å lage en oppføringsforhåndsvisning. I
Det første eksempelet var lengden på forhåndsvisningen hardkodet inn i funksjonen,
som vi bestemte oss for er en dårlig praksis. I denne funksjonen vil vi passere to parametere
til vår kode: teksten som skal behandles, og antall ord vi vil vise som
vår forhåndsvisning.
La oss begynne med å se på funksjonen:
funksjon createTextPreview ($ text, $ length = 25) / * * Bryt teksten fra hverandre i mellomrom og opprett forhåndsvisningsvariabelen * / $ words = explode (", $ text); $ forhåndsvisning = NULL; / * * Kjør en sløyfe for å legge til ord i forhåndsvisningsvariabelen * / hvis ($ lengde < count($words)) for($i=0; $i<$length; $i++) $preview .= $words[$i] ."; // Add the space back in between words $preview .= $words[$length] . '… '; // Ellipsis to indicate preview else /* * If the entry isn't as long as the specified preview length, simply * return the whole entry. */ $preview = $text; /* * Return the preview */ return $preview; I funksjonen ovenfor kontrollerer vi bare at antall ord i den medfølgende
Oppføringen er større enn antall ord vi vil vise i forhåndsvisningen vår, da
legg til ord i den nyopprettede $ forhåndsvisningsvariabelen en om gangen til vi treffer vår
mållengde, hvor vi legger til en ellipse og returnerer $ forhåndsvisning.
Akkurat som i vår databaserivå holder vi koden innenfor grensen til
forretningsnivå. Alt vi gjør er å skape en tekst forhåndsvisning; det er ingen
samspill med databasen, og ingen presentasjonselementer som HTML
markup.
Til slutt må vi vise dataene vi har hentet og behandlet. For vår
Formålene vil vi vise det med ekstremt enkelt HTML-oppslag:
Ideen bak denne koden er enkel: Først, legg inn oppføringene med vår
databasefunksjon, deretter løp gjennom oppføringene, forkort inntekstteksten
bruker forhåndsvisningsfunksjonen og plasserer deretter tittel og oppføringsforhåndsvisning i
presentasjonssammenheng.
Nå, for å endre oppsettet for forhåndsvisningene, kun to linjer med
HTML må justeres. Dette er langt mindre forvirrende enn originalen
funksjon som håndterte alle tre nivåer.
Jeg vil påpeke at eksemplet ovenfor er veldig grunnleggende, og er bare ment å
demonstrere begrepet tiered programmering. Tanken er at ved å holde
forskjellige typer programmeringslogikk skilt, kan du øke enormt
lesbarhet og vedlikehold av koden din.
MERK: Det er en flott artikkel
på TheDailyWTF.com diskutere bruk og misbruk av tiered programvare design, og
fantastisk kommentar på
artikkel som presenterer ulike meninger. Multi-tiered applikasjoner er ekstremt nyttig, men også lett å
misforstå og overkomplisere, så husk å grundig planlegge programvaren din før du bygger for å unngå å forårsake
flere problemer enn du løser.
Har du noen tanker om tiered applikasjoner? Hvilke trinn tar du til
maksimere brukervennlighet og fremtidige endringer i koden du skriver? La oss
vet i kommentarene!
