Eile andsin hoidla mustrile krundi. Lühidalt öeldes on see üks neist mustritest, millest peaks minu arvates aru saama igaüks, kes töötab WordPressi peale ehitatud vahevaraga.
Sellisele mustrile kruntvärvi andmisel võib olla keeruline mustrile õiglust anda, kui teil on vaja:
- tutvustage seda,
- selgitage, kuidas see töötab,
- katta hüved,
- ja tee väike demo.
Kuid hoidla tegelik eelis ei seisne mitte ainult andmekihi eraldamises ülejäänud rakendusest, vaid selles, et seda saab (või peaks) saama hõlpsasti vahetada erinevate andmesalvedega ilma API-d muutmata.
Näiteks ühel juhul peate võib-olla hankima andmed WordPressi andmebaasist, teistel juhtudel peate võib-olla hankima midagi kolmanda osapoole API-st või võib-olla on mõni muu koht, kust peate andmeid hankima.
Hoolimata sellest seisneb hoidla mustri idee selles, et mis iganes selle taga asub, ei oma tähtsust seni, kuni selle pakutav API töötab seda kutsuva rakenduse kihi jaoks.
Ja kuna oleme käsitlenud hoidla mustri aabitsat, vaatame mõnda hoidla mustri eelist ja seda, kuidas saaksime seda WordPressi projektide kontekstis rakendada.
Hoidla mustri eelised
Mustri selgitamise alustamiseks on mõned viisid, seega alustan lihtsa diagrammiga:
Hoidla mustri eelised hõlmavad andmehoidla abstraktsiooni
Pange tähele, et ülaloleval pildil on kolm põhikomponenti:
- domeeniloogika (või äriloogika), mille olen sildistanud rakenduseks,
- hoidla,
- andmehoidla,
Rakenduse osas jäävad ärireeglid alati suhteliselt järjepidevaks. Vähemalt peaksid, eks?
Hoidla on see, mis toimib sidevahendina äriloogika ja andmesalve vahel.
Nüüd võib andmesalv olla andmebaas, võib-olla failide komplekt (mida ma ei soovitaks), API kolmandale osapoolele, teisest rakendusest hangitud teabe loend jne.
Asi on selles, et hoidla pakub puhast API-d, millele äriloogika saab kirjutada ja millest lugeda (ja sellest hetkega rohkem), ilma et peaks muretsema üksikasjade pärast, kuhu andmed liiguvad või kuidas need tagasi tulevad.
See on hoidla ülesanne. Ja see teebki oluliseks järjepideva API olemasolu ja just seetõttu on oluline tagada, et sellel on selle andmesalve juurutamise üksikasjad, millega see suhtleb.
Sidumisel
Peale selle, et teie rakendus on õigesti segmenteeritud, on hoidla muster arhitektuurile kasulik, kuna see aitab teie rakenduse osi lahti siduda.
See tähendab, et äriloogika ei tea midagi selle kohta, kuidas või kus andmeid hoitakse. Ta lihtsalt teab, et suudab seda kirjutada ja hankida ning saab seda teha puhta API abil.
Hoidla vastutab nimetatud andmesalve edastamise eest, et korraldada serialiseerimist ja otsimist, kuid see peab pakkuma ühtset API-d, nii et andmekiht ei pea oma teabe lugemiseks ja kirjutamiseks süntaksiharjutusi tegema.
Rakenduse üksikasjad
Kuni selle hetkeni olen esindanud hoidlat konkreetse klassina.
Asi on selles, et rakendusel on tõenäoliselt mitu hoidlat. Ja seetõttu on hea mõte omada liideseid, mida iga hoidla saab rakendada.
Nii saate määratleda hoidla pakutavate meetodite lepingu. Ja nii saate tagada, et iga hoidla on ühendatud õige andmesalvega.
Liidese teostus mitme hoidla jaoks.
Oletame, et teie rakendus peab suhtlema nii WordPressi andmebaasiga kui ka kolmanda osapoole API-ga.
Ideaaljuhul pakuks liides ühtset meetodite komplekti, kuid juurutamise üksikasjad varieeruksid hoidlapõhiselt, kuna igal hoidlal on vajalikud mandaadid ja võime andmesalvega suhelda.
Liidese edenemine annab aga mustrile selle jõu. Domeeniloogika ei pea muretsema selle pärast, kuidas teavet salvestatakse või kuidas see välja tuuakse. See lihtsalt kutsub liideses määratletud meetodeid ja vajalik objekt hoolitseb selle eest.
See lihtsalt kutsub liideses määratletud meetodeid ja vajalik objekt hoolitseb selle eest.
Kuidas see WordPressis välja näeks?
See on hea küsimus (ja ei, ma ei mõelnud seda välja lihtsalt selleks, et sellele ise vastata 🙂) ja suurepärast näidet võib olla raske tuua, kuna suur osa meie tegemistest suhtleb otse WordPressi andmebaasiga.
See ei tähenda, et meil poleks kasutada abstraktsioone, nagu postitused, lehed, kasutajad või mis tahes muud kohandatud postituse tüübid, mille loomiseks otsustame.
Kuid WordPress pakub suure osa jaoks API-d. Näen juhtumit, kus näiteks kasutaja, kellel on lisatud täiendavaid välju, võiks kasu saada kasutajahoidlast.
Või võib hoidlast kasu saada ka kohandatud postituse tüüp, millel on palju metaandmeid, kuna üksikasjad on hoidlasse kapseldatud.
Kõrgetasemeline näide
Oletagem näiteks, et teil on sündmuse jaoks kohandatud postituse tüüp ning sündmuse pealkiri ja kirjeldus, mis loomulikult sobiksid postituse pealkirja ja postituse sisuga.
Kuid siis on sellel metaandmed oma asukoha, algusaja, lõpuaja ja muu kohta. Selle võib ka hoidla kapseldada, et saaksite omada sündmuse objekti, edastada selle hoidlasse ja lasta hoidlal saata teave õigesse kohta andmebaasis.
Sama kehtib ka teabe hankimise kohta: ta teab, kust seda hankida, kuidas sündmuse objekti sisestada ja seejärel helistajale tagasi anda.
Tagasi õigele teele
Kuid kogu see jutt sündmusest läheb teemast veidi kõrvale, nii et võib-olla jätkan sellest rääkimist ja sellest, kuidas see hoidlaga sobib, ühes järelpostituses. Selge on see, et sellest rääkides on palju käsitleda.
Ma eelistan seda teha väiksemate sammudega
Lühidalt, kui teil on sündmuste hoidla, on teil tõenäoliselt sündmuse objekt või sündmuse olem. Ja kuidas see sobib WordPressi, kohandatud postitustüüpide, metaandmete ja muuga, toob kaasa keerukuse taseme, mis võib alguses tunduda hirmutav, kuid lõpuks tasub end ära suurema veebirakendusega töötades.