Aina kun työskentelet suuremman WordPressiin perustuvan projektin parissa, todennäköisyys, että työskentelet useamman kuin yhden tietolähteen – eli WordPress-tietokannan – kanssa, on normaalia korkeampi. Saatat esimerkiksi työskennellä projektin parissa, jonka on koordinoitava tietoja:
- WordPress-tietokanta,
- help desk -lippujärjestelmä,
- sisällön tuontijärjestelmä,
- toinen kolmannen osapuolen sovellusliittymä,
- ja mahdollista muutakin.
Ja kun näin tapahtuu, voi tulla hieman hankalaa kirjoittaa koodia, jonka avulla on helppo hakea tietoa eri paikoista. Tästä kehittäjät yleensä puhuvat, kun he viittaavat "tasojen" käsittelyyn sovelluksessaan.
- on kerroksia tietojen esittämiseksi käyttäjälle,
kerroksia liiketoimintalogiikan (tai toimialueen logiikan) käsittelemiseksi, - kerrokset kommunikointiin API:iden kanssa,
- ja kerrokset tietojen tallentamista varten.
Rehellisesti sanottuna sinun ei tarvitse olla useita tietovarastoja katsellaksesi luodaksesi kerroksen, joka helpottaa tietojen lähettämistä ja hakemista tietokannasta, juuri silloin se on yleisempää. Voit yhtä tehokkaasti työskennellä yksittäisen tietovaraston, kuten WordPress-tietokannan, kanssa, kun toteutat arkistomallia.
Siitä huolimatta, jos olet rakentamassa suurempaa verkkosivustoa, verkkosovellusta tai laajennusta, arkistomallin toteuttaminen voi maksaa ylläpidon, koodin selkeyden ja huolenaiheiden erottamisen.
Mutta miten tämä voidaan toteuttaa WordPressissä? Se ei ole hirveän haastavaa, mutta ensin kannattaa tarkistaa arkiston aluke ennen kuin hyppäät mihinkään koodiin.
Varastokuviopohjamaali
Ennen kuin tarkastelet todellista toteutusta WordPressissä, on tärkeää ymmärtää, mikä arkisto on, miten se on määritelty, mitä se tarjoaa ja sen yleinen toteutus. Jaan lisää luettavaa artikkelin lopussa, mutta siihen asti käsittelen yleistä näkemystäni mallista täällä.
Ensinnäkin tämän mallin toteuttamisesta voi tulla monimutkaisempi kuin aloittelijoille on tarpeen. Tämä ei tarkoita, etteikö varsinainen kuvio olisi ymmärtämisen arvoinen, mutta jos haluat vain kastella itseäsi tällä, en ole lukijoiden heittämisen ystävä syvään. En usko, että se on paras tapa oppia.
Sen sijaan kannattaa purkaa ongelma ja rakentaa se sitten uudelleen hieman tyylikkäämmäksi. Joten se on se, mitä aion tehdä.
Sana irrottamisesta
Kun puhutaan olio-ohjelmoinnista, puhumme usein ajatuksesta "irrottaa" järjestelmän osia. Jos tunnet kytkennän ja koheesion, tiedät miksi.
Mutta jos ei, riittää, kun totean, että mitä enemmän järjestelmän komponentit on kytketty, sitä vaikeampi on muuttaa niitä. He tietävät liikaa toisistaan. Eli jos muutat jotakin järjestelmän osa-aluetta, se todennäköisesti kaskadee tai vaikuttaa järjestelmän toiseen osaan, jota et koskaan tarkoittanut tapahtuvan. Sitten sinun on käytettävä paljon enemmän aikaa kaikkien näiden muiden "kosketuspisteiden" korjaamiseen koko järjestelmässä, minkä ei pitäisi olla tarpeellista.
Erilaisten strategioiden, kuten arkiston mallin, käyttöönotto voi auttaa irrottamaan järjestelmän osia. Esimerkki: Esityskerros ei tiedä, miten taustalla oleva tietovarasto on organisaatio. Sen ei tarvitse osata SQL:ää. Sen ei tarvitse tietää, että se on tietokanta. Sen sijaan sen on vain osattava puhua arkiston kanssa.
Hienoa, eikö?
Tämä tarkoittaa, että voit vaihtaa taustatietosäilön ja olettaen, että API on vakaa; sovelluksesi toimii edelleen ilman muutoksia. Ja sitä tarkoittaa olla todella irrotettu.
Arkistomallin toteutus
Miltä arkiston malli sitten näyttää? Kuten useimmissa suunnittelumalleissa, kuviossa on yleinen muoto, ja se on aina hyödyllistä, mutta mielestäni se auttaa myös meitä WordPressissä työskenteleviä näkemään, kuinka se voisi toimia WordPressin yhteydessä.
Joten ensin haluan hajottaa itse kuvion ja antaa sitten esimerkin siitä, miltä se saattaa näyttää työskennellessäni WordPressin kanssa.
Arkistomallin yleinen toteutus
Arkistomallin varsinainen toteutus on melko yksinkertaista. Itse asiassa en ole koskaan varma, onko se niin hyödyllinen, koska se näyttää vain, kuinka tietovarastot, arkisto ja muu sovellus ovat vuorovaikutuksessa keskenään.
Älä ymmärrä minua väärin: kannatan käsitteellisiä malleja asioiden järjestämisestä. Henkilökohtaisesti se auttaa minua miettimään sovelluksen rakennetta sitä rakentaessani, mutta jos se on liian yleinen, siitä ei ole paljon apua.
Mutta päästäksemme konkreettiseen toteutukseen meidän on aloitettava jostain, eikö niin? Joten aloitan korkeimmalla mahdollisella tasolla ja työskentelen alaspäin.
Kuten yllä olevasta kuvasta näkyy, sinulla on pari tietovarastoa, jotka kaikki luetaan arkiston kautta, ja sitten sovellus kysyy arkistosta, joka puolestaan hakee tietoja tietovarastosta.
Kyllä, on vaihtoehtoja tallentaa tiedot välimuistiin, mitätöidä välimuisti ja kaikkea muuta hauskaa. Mutta se ei kuulu arkiston ensisijaisen piiriin. Joten en aio mennä tällä tiellä toistaiseksi. Ehkä jossain tulevassa postauksessa (jos tämä osoittautuu hyödylliseksi sinulle).
Arkistomalli WordPressissä
Tämän jälkeen katsotaanpa perustoteutusta siitä, miltä tämä voisi näyttää tavallisessa WordPress-asennuksessa. Eli kaikki, mitä meillä on, on tietovarasto. Emme kommunikoi minkään muun kanssa, mutta haluamme varmistaa, että arkisto käsittelee kaiken, mikä liittyy tietokantaan tai API:hen.
Tämä näyttäisi suunnilleen tältä:
Miltä se voisi näyttää WordPressin kanssa
Ja tätä voidaan abstraktoida vielä pidemmälle. Ehkä siellä on viestivarasto tai käyttäjäarkisto. Henkilökohtaisesti pidän arkistosta jokaiselle entiteettityypille, koska se auttaa hillitsemään liittyvää liiketoimintalogiikkaa luomatta niitä suuria luokkia, jotka tietävät kaiken (ja tarpeettomasti).
Tämä voi siis näyttää tältä:
Arkiston paketti
Nostetaan sitten vielä yksi taso ja sanotaan, että työskentelet Twitter API:n, ZenDesk API:n, WordPress User API:n ja WordPress Post API:n kanssa. Mitä sitten? Tietovarastoja on enemmän.
Ehkä ne sisältyvät nimiavaruuteensa (mikä niiden pitäisi olla), ehkä ne toteuttavat yhteistä käyttöliittymää (jolle on syytä), mutta kehitysvaiheessa mielestäni on tärkeää kertoa selkeästi, mitä arkistoa käytät. jotta se olisi mahdollisimman selkeä.
Eli älä käytä yleistä ja anna suoritusajan selvittää se:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );Ole sen sijaan selkeä:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );Tämä saattaa tuntua paljon. En tiedä, koetko tämän, mutta olio-ohjelmoinnissa on outo tunne, kun haluamme luoda pieniä, kohdennettuja luokkia, mutta se luo paljon tiedostoja.
Joten sinulla on nämä siististi asetetut tiedostot, joista jokainen tekee jotain pientä ja tarkoituksenmukaista. Älä anna projektin muodostavien tiedostojen määrän antaa vaikutelmaa, että sinulla on huono arkkitehtuuri.
Johtopäätös
Tämä on arkiston kuvion aluke. Luonnollisesti tähän liittyy koodia, mutta ennen kuin sukelsin siihen osaan – koska koodissa asiat, jotka häviävät helposti käännöksissä – halusin varmistaa, että autin antamaan havainnollistamisen käsitteellisen mallin kehittämisessä mallin toiminnasta.
Tästä eteenpäin voimme alkaa puhua mallin toteutuksesta. Joten seuraavan postauksen tai parin seuraavan postauksen aikana aion tehdä juuri niin.
Sillä välin älä epäröi jättää kommentteja tai kysymyksiä siitä, mitä täällä on käsitelty.