Arkiston mallin edut: miksi meidän pitäisi harkita sitä
Eilen annoin pohjamaalin arkiston kuviolle. Lyhyesti sanottuna se on yksi niistä malleista, jotka mielestäni jokaisen WordPressin päälle rakennetun väliohjelmiston parissa työskentelevien pitäisi ymmärtää.
Kun annat pohjamaalin tällaiselle kuviolle, voi olla vaikeaa tehdä oikeutta kuviolle, kun tarvitset:
- esitellä se,
- selittää miten se toimii,
- kattaa edut,
- ja anna pieni esittely.
Mutta arkiston todellinen etu ei ole vain tietokerroksen poistaminen muusta sovelluksesta, vaan se voidaan (tai sen pitäisi) olla helposti vaihdettavissa eri tietovarastoihin ilman API:ta vaihtamatta.
Esimerkiksi yhdessä tapauksessa saatat joutua hakemaan tietoja WordPress-tietokannasta, toisissa tapauksissa saatat joutua hakemaan jotain kolmannen osapuolen API:sta tai ehkä jostain muusta paikasta sinun täytyy hakea tietoja.
Siitä huolimatta arkistomallin taustalla oleva ajatus on, että sillä, mitä sen takana on, ei ole väliä, kunhan sen tarjoama API toimii sitä kutsuvan sovelluksen kerrokselle.
Ja koska olemme käsitelleet arkistomallin pohjapiirroksen, katsotaanpa joitain arkistomallin etuja ja kuinka voimme toteuttaa sen WordPress-projektien yhteydessä.
Varastomallin edut
On joitakin tapoja aloittaa kuvion selittäminen, joten aloitan yksinkertaisella kaaviolla:
Tietovarastomallin etuihin kuuluu Data Store Abstraction
Huomaa yllä olevassa kuvassa, että siinä on kolme pääkomponenttia:
- verkkotunnuksen logiikka (tai liiketoimintalogiikka), jonka olen merkinnyt sovellukseksi,
- arkisto,
- tietovarasto,
Sovelluksen osalta liiketoimintasäännöt pysyvät aina suhteellisen johdonmukaisina. Ainakin niiden pitäisi, eikö?
Tietovarasto toimii viestintävälineenä liiketoimintalogiikan ja tietovaraston välillä.
Nyt tietovarasto voi olla tietokanta, ehkä tiedostojoukko (jota en suosittele), API kolmannelle osapuolelle, luettelo toisesta sovelluksesta haetuista tiedoista ja niin edelleen.
Asia on siinä, että arkisto tarjoaa puhtaan API:n, jolle liiketoimintalogiikka voi kirjoittaa ja josta voi lukea (ja lisää tästä hetkessä) ilman huolta siitä, mihin tiedot menevät tai miten ne tulevat takaisin.
Se on arkiston tehtävä. Ja siksi on tärkeää, että sovellusliittymä on johdonmukainen, ja siksi on tärkeää varmistaa, että sillä on sen tietovaraston toteutustiedot, jonka kanssa se on vuorovaikutuksessa.
Kytkennässä
Sen lisäksi, että sovelluksesi on segmentoitu oikein, arkistokuvio hyödyttää arkkitehtuuria, koska se auttaa erottamaan sovelluksesi osat.
Eli liiketoimintalogiikka ei tiedä mitään siitä, miten tai missä tiedot tallennetaan. Se vain tietää, että se voi kirjoittaa sen ja hakea sen ja voi tehdä sen puhtaan API:n avulla.
Tietovarasto on vastuussa mainitun tietovaraston viestimisestä sarjoittamista ja noutoa varten, mutta sen on tarjottava johdonmukainen API, joten tietokerroksen ei tarvitse tehdä syntaksisia harjoituksia tietojensa lukemiseksi ja kirjoittamiseksi.
Toteutustiedot
Tähän asti olen edustanut arkistoa konkreettisena luokkana.
Asia on, että sovelluksella on todennäköisesti useita tietovarastoja. Ja sen vuoksi on hyvä idea olla rajapintoja, jotka jokainen arkisto voi toteuttaa.
Näin määrität arkiston tarjoamien menetelmien sopimuksen. Ja tällä tavalla voit varmistaa, että jokainen arkisto on yhdistetty oikeaan tietovarastoon.
Käyttöliittymätoteutus useille tietovarastoille.
Oletetaan siis, että sovelluksesi on keskusteltava WordPress-tietokannan sekä kolmannen osapuolen API:n kanssa.
Ihannetapauksessa käyttöliittymä tarjoaisi yhteiset menetelmät, mutta toteutustiedot vaihtelevat arkiston mukaan, koska jokaisella arkistolla on tarvittavat valtuustiedot ja kyky kommunikoida tietovaraston kanssa.
Eteneminen käyttöliittymään on kuitenkin se, mikä antaa kuviolle sen voiman. Verkkotunnuksen logiikan ei tarvitse huolehtia siitä, kuinka tiedot tallennetaan tai miten ne haetaan. Se yksinkertaisesti kutsuu käyttöliittymässä määritellyt menetelmät ja tarvittava objekti huolehtii siitä.
Se yksinkertaisesti kutsuu käyttöliittymässä määritellyt menetelmät ja tarvittava objekti huolehtii siitä.
Miltä tämä näyttäisi WordPressissä?
Tämä on hyvä kysymys (ja ei, en keksinyt sitä vain vastatakseni siihen itse 🙂), ja voi olla vaikea antaa loistavaa esimerkkiä, koska niin suuri osa tekemisistämme on vuorovaikutuksessa suoraan WordPress-tietokannan kanssa.
Tämä ei tarkoita, etteikö voisi käyttää abstraktioita, kuten viestejä, sivuja, käyttäjiä tai mitä tahansa muita mukautettuja viestityyppejä, joita valitsemme luoda.
Mutta WordPress tarjoaa API:n suurelle osalle tästä. Näen tapauksen, jossa esimerkiksi käyttäjä, jolla on lisäkenttiä, voisi hyötyä käyttäjävarastosta.
Tai mukautettu postaustyyppi, jossa on paljon metatietoja, voisi myös hyötyä arkistosta, jos tiedot on kapseloitu arkistoon.
Korkean tason esimerkki
Oletetaan esimerkiksi, että sinulla on tapahtumalle mukautettu viestityyppi, ja tapahtumalla on otsikko ja kuvaus, jotka luonnollisesti sopivat postauksen otsikkoon ja sisältöön.
Mutta sitten sillä on metatiedot sijainnistaan, alkamisajasta, päättymisajasta ja niin edelleen. Tietovarasto voi myös kapseloida sen, jotta sinulla voisi olla Tapahtuma-objekti, välittää se arkistoon ja antaa arkiston lähettää tiedot oikeaan paikkaan tietokannassa.
Ja sama pätee tietojen hakemiseen: Se tietää, mistä ne saa, miten tapahtumaobjekti täytetään ja palautetaan sitten soittajalle.
Takaisin raiteilleen
Mutta kaikki tämä tapahtumasta puhuminen on menossa hieman aiheen vierestä, joten ehkä jatkan keskustelua siitä ja kuinka se sopii arkiston kanssa jatkopostauksessa. On selvää, että kun puhutaan tästä, on paljon katettavaa.
Otan sen mieluummin pienin askelin
Lyhyesti sanottuna, jos sinulla on tapahtumatietovarasto, sinulla on todennäköisesti tapahtumaobjekti tai tapahtumakokonaisuus. Ja se, miten tämä sopii WordPressiin, mukautettuihin viestityyppeihin, metatietoihin ja niin edelleen, tuo monimutkaisuuden tason, joka saattaa aluksi tuntua pelottavalta, mutta lopulta kannattaa, kun työskentelet suuremman verkkosovelluksen kanssa.