Kui töötate suurema WordPressil põhineva projekti kallal, on tõenäosus, et töötate rohkem kui ühe andmeallikaga – st WordPressi andmebaasiga – tavalisest suurem. Näiteks võite töötada projekti kallal, mis peab koordineerima teavet:
- WordPressi andmebaas,
- kasutajatoe piletimüügisüsteem,
- sisu importimise süsteem,
- muu kolmanda osapoole API,
- ja võimalik rohkemgi.
Ja kui see juhtub, võib olla veidi tülikas kirjutada koodi, mis hõlbustab teabe hankimist erinevatest kohtadest. Sellest tavaliselt räägivad arendajad, kui nad viitavad oma rakenduses "kihtide" käsitlemisele.
- on kihid teabe esitamiseks kasutajale,
kihid äriloogika (või domeeniloogika) käsitlemiseks, - API-dega suhtlemise kihid,
- ja kihid andmete salvestamiseks.
Ausalt öeldes ei pea te jälgimiseks omama erinevaid andmesalve, et luua kiht, mis lihtsustab andmete saatmist ja sealt väljavõtmist, just siis on see tavalisem. Hoidla mustri rakendamisel saate sama tõhusalt töötada ühe andmesalvega, näiteks WordPressi andmebaasiga.
Olenemata sellest, kui loote suuremat veebisaiti, veebirakendust või pistikprogrammi, võib hoidla mustri rakendamine teenida kasu hoolduse, koodi selguse ja probleemide eraldamise osas.
Kuid kuidas saaks seda WordPressis rakendada? See ei ole väga keeruline, kuid kõigepealt tasub enne mis tahes koodi juurde hüppamist üle vaadata hoidla aabits.
Hoidla mustri kruntvärv
Enne WordPressi tegeliku juurutamise vaatamist on oluline mõista, mis hoidla on, kuidas see on määratletud, mida see pakub ja selle üldist juurutust. Jagan artikli lõpus täiendavat lugemist, kuid seni käsitlen siin oma üldist mustrit.
Esiteks võib selle mustri rakendamine muutuda algajatele vajalikust keerulisemaks. See ei tähenda, et tegelik muster ei vääriks mõistmist, kuid kui tahate end sellega lihtsalt märjaks saada, ei ole ma lugejate sügavasse otsa viskamise fänn. Ma ei arva, et see on parim viis õppimiseks.
Selle asemel tasub probleem lahti murda ja siis see millekski veidi elegantsemaks ümber ehitada. Nii et see on see, mida ma kavatsen teha.
Mõni sõna lahtisidumise kohta
Objektorienteeritud programmeerimisest rääkides räägime sageli süsteemi osade lahtisidumise ideest. Kui olete sidumise ja ühtekuuluvusega tuttav, siis teate, miks.
Kui aga mitte, siis piisab, kui öelda, et mida rohkem ühendatud on teie süsteemi komponendid, seda raskem on neid muuta. Nad teavad üksteisest liiga palju. See tähendab, et kui muudate mõnda süsteemi aspekti, siis tõenäoliselt läheb see kaskaadiks või mõjutab süsteemi teist osa, mida te kunagi ei kavatsenud juhtuda. Siis jääte üle, kui peate kulutama palju rohkem aega kõigi nende muude "puutepunktide" parandamisele kogu süsteemis, mis ei peaks olema vajalik.
Erinevate strateegiate (nt hoidla muster) rakendamine võib aidata süsteemi osi lahti siduda. Näide: esitluskiht ei tea, kuidas selle aluseks olev andmesalv on organiseeritud. See ei pea SQL-i teadma. See ei pea teadma, et see on andmebaas. Selle asemel peab see lihtsalt teadma, kuidas hoidlaga rääkida.
Tore, eks?
See tähendab, et saate taustaandmete salve välja vahetada ja eeldusel, et teie API on kindel; teie rakendus jätkab töötamist ilma muudatusteta. Ja seda tähendabki olla tõeliselt lahutatud.
Hoidla mustri rakendamine
Kuidas siis hoidla muster välja näeb? Nagu enamiku kujundusmustrite puhul, on mustril ka üldine vorm ja see on alati kasulik, kuid ma arvan, et see aitab ka meil, kes WordPressis töötavad, näha, kuidas see võiks WordPressi kontekstis töötada.
Esiteks tahan ma mustri enda lahti teha ja seejärel tuua näite, milline see WordPressiga töötades välja näeb.
Hoidla mustri üldine teostus
Hoidla mustri tegelik rakendamine on üsna lihtne. Tegelikult pole ma kunagi kindel, kas see on nii kasulik, sest see lihtsalt näitab, kuidas andmesalved, hoidla ja ülejäänud rakendus omavahel suhtlevad.
Ärge saage minust valesti aru: pooldan asjade korraldamise kontseptuaalseid mudeleid. Minul isiklikult aitab see rakenduse ehitamisel mõelda selle ülesehitusele, aga kui see on liiga üldine, pole sellest palju abi.
Kuid selleks, et jõuda konkreetse töövahendini, peame kuskilt alustama, eks? Nii et alustan võimalikult kõrgelt tasemelt ja töötan allapoole.
Nagu näete ülaltoodud pildil, on teil paar andmesalvet, mida kõiki loetakse hoidla kaudu, ja seejärel teeb rakendus hoidlast päringu, mis omakorda hangib andmesalvest teavet.
Jah, on võimalusi teabe vahemällu salvestamiseks, vahemälu kehtetuks muutmiseks ja muuks muuks lõbusaks. Kuid see on väljaspool hoidla esmase funktsiooni ulatust. Nii et ma ei lähe praegu sellele konkreetsele teele. Võib-olla mõnes tulevases postituses (kui see peaks teile kasulikuks osutuma).
WordPressi hoidla muster
Seda arvestades vaatame põhirakendust selle kohta, kuidas see standardse WordPressi installi puhul välja näeb. See tähendab, et meil on ainult andmesalv. Me ei suhtle millegi muuga, kuid tahame olla kindlad, et hoidla käsitleb kõike, mis on liidesega andmebaasi või API-ga
See näeks välja umbes selline:
Kuidas see WordPressiga välja näeb
Ja seda saab veelgi abstraktsemalt võtta. Võib-olla on seal postituste hoidla või kasutajate hoidla. Isiklikult olen selle fänn, et igat tüüpi olemi jaoks on hoidla, kuna see aitab kaasata seotud äriloogikale, ilma et tekiks suuri klasse, mis teavad kõike (ja asjatult).
Nii et see võib välja näha selline:
Hoidlate pakett
Seejärel tõstkem see veel ühe taseme võrra kõrgemale ja ütleme, et töötate Twitteri API, ZenDeski API, WordPressi kasutaja API ja WordPress Posti API-ga. Siis mida? Hoidlaid on rohkem.
Võib-olla sisalduvad need nende nimeruumis (mis nad peaksid olema), võib-olla rakendavad nad ühist liidest (mille jaoks on selleks põhjus), kuid arenduse ajal on minu arvates oluline selgelt öelda, millist hoidlat te kasutate. et see oleks võimalikult selge.
See tähendab, et ärge kasutage üldist ja laske käitusajal see välja mõelda:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );Selle asemel olge selgesõnaline:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );See võib tunduda palju. Ma ei tea, kas te seda kogete, kuid objektorienteeritud programmeerimisel on veider tunne, kus me tahame luua väikseid, keskendunud klasse, kuid see loob palju faile.
Nii et teil on need korralikult seadistatud failid, millest igaüks teeb midagi väikest ja sihipärast. Ärge laske projekti koostavate failide arvul jätta muljet, et teil on kehv arhitektuur.
Järeldus
See on hoidla mustri praimer. Loomulikult on sellega kaasas kood, kuid enne sellesse ossa sukeldumist – kuna kood on koht, kus asjad lähevad tõlkimisel kergesti kaduma – tahtsin veenduda, et aitasin luua illustratsiooni mustri toimimise kontseptuaalse mudeli väljatöötamiseks.
Siit saame hakata rääkima mustri rakendamisest. Nii et järgmise postituse või paari järgmise postituse jooksul teen täpselt seda.
Seni ärge kõhelge jätke kommentaare või küsimusi siin käsitletu kohta.