Adattár tervezési mintája gyorsan

Tiszta módszer a modellek lekérdezésére

Milyen problémát old meg?

Ha újra és újra lekérdeznie kell a modell objektumait a kód különböző pontjaiból, a tárház valóban hasznos lehet, ha egyetlen belépési pontot biztosít a modellekkel való együttműködéshez, és eltávolítja a duplikált lekérdezési kódot. Még tovább megy, és használhatja a protokollokkal, így könnyedén kikapcsolhatja a megvalósításokat (például az egységteszthez), vagy pedig a generikumokkal több * dobtekercs * általános absztrakcióhoz használhatja. Ebben a cikkben ezeket az eseteket tárgyalom.

A jelenet vázlata.

Tegyük fel, hogy van valamilyen kódja, amely adatokat von le egy API-tól, és leképezi ezt az objektumok modellezésére. Ebben a példában egy szerverről fogok lekérni a cikkek listáját.

Ez kissé funkcionálisnak tűnhet, de ez csak az RxSwift, amikor a Moyt használjuk hálózati absztrakciós rétegként, de nem igazán számít, hogy megértsük, mi történik. Az, hogy hogyan tölti le az adatait, teljesen rajtad múlik.

Ez a kóddarab megteszi

  1. GET kérés a szerverhez
  2. A visszatérő JSON-t hozzárendelheti egy cikkobjektumok tömbjéhez
  3. A bezárást akkor hívják meg, amikor az összes munka elkészült.

Miért van szükségünk egy adattárra?

Nos, abban a pillanatban nem. Ha csak egyszer hívja meg az API-t a teljes kódbázisban, akkor a tárház hozzáadása túlsúlyos lehet (vagy amint egyesek szerint túltervezés).

Rendben ... de mikor használható a tárolóobjektum?
Tegyük fel, hogy a kódbázisod növekedni kezd, és meg kell írnia a kódot, hogy újra és újra letöltse a cikkeket. Azt mondhatja: „másoljuk ki a kódot, és illessze be, bárhová kell letölteni az összes cikket”.

Nem ártott, senki sem halt meg. Jobb?

Abban a pillanatban egy nagy piros riasztásnak kell villognia az agyában.

Helló tároló.

A lerakat csak egy objektum, amely az összes kódot beilleszti egy modell lekérdezésére a modellekbe, tehát egyetlen belépési pontja van, ha pl. kapd meg az összes cikket.

Hozzunk létre egy tárolóobjektumot, amely nyilvános API-t biztosít a cikkek beszerzéséhez.

Most felhívhatjuk ezt a módszert, és nem kell aggódnunk, mi történik a színfalak mögött, hogy a tényleges cikkeket megkapjuk.
Csak hívja a módszert, és megkapja a cikkeket. Szép, igaz?
De várjon, van még!

Kezelje az összes cikk-interakciót

A lerakat segítségével további módszereket adhatunk a modellobjektumunkkal való interakcióhoz. A legtöbb alkalommal, amikor CRUD (létrehozás, olvasás, frissítés, törlés) műveleteket akar végezni a modelljén. Nos, csak adja hozzá a tárolóba ezen műveletek logikáját.

Ez egy szép API-t tesz lehetővé, amely az egész kódban használható, anélkül, hogy ugyanazt a kódot újra és újra meg kellene ismételni.

A gyakorlatban a tárház használata így nézne ki.

Elég szép és olvasható, igaz? De várjon, még jobb lesz.

Bekapcsolás: protokollok

Az előző kódban mindig használtam „az adatok API-n történő beszerzése” példát. De mi lenne, ha támogatást kell hozzáadnia egy helyi JSON-fájlból az online forrás helyett az adatok betöltéséhez.

Nos, ha olyan protokollt hoz létre, amely felsorolja a metódusneveket, létrehozhat egy implementációt az online API-hoz, és egyet az adatok offline eléréséhez.

Ez így nézhet ki.

Egy protokoll csak azt mondja: „Ha megfelel engem, akkor rendelkeznie kell ezekkel a módszerekkel, de nem érdekel a tényleges megvalósítás!”

Ez nagyszerű, létrehozhat egy WebArticleRepositoryt és egy LocalArticleRepositoryt. Mindkettő rendelkezik az összes módszerrel, amely fel van sorolva a protokollban, de 2 teljesen eltérő megvalósítást is írhat.

Bekapcsolás: egység tesztelése

A protokollok használata akkor is nagyon kényelmes, ha egyedileg tesztelni szeretné a kódot, mert létrehozhat egy másik objektumot, amely megvalósítja a lerakatprotokollot, hanem ehelyett állati adatokat ad vissza.

Ha ezt függőség-befecskendezéssel együtt használja, akkor nagyon könnyű egy adott tárgy tesztelése.

Egy példa

Tegyük fel, hogy van nézetmodellje, és a nézetmodell adatait egy lerakaton keresztül kapja meg.

Ha ki akarja tesztelni a nézetmodellt, akkor ragadt a cikkekhez, amelyeket az internetről tölt be.
Valójában nem ezt akarjuk. Azt akarjuk, hogy a teszt a lehető legnagyobb mértékben determinisztikus legyen. Ebben az esetben az internetről kinyert cikkek idővel változhatnak, a tesztek futtatásakor nem lehet internet-kapcsolat, a szerver leállhat… ezek az összes lehetséges forgatókönyv, amelyben a teszteink kudarcot vallnak, mert ők ellenőrizetlen És amikor tesztelünk, ellenőrizni akarjuk / kell.

Szerencsére ezt nagyon egyszerű megoldani.

Helló, függőségi injekció.

Be kell állítania a ArticleRepo tulajdonságot az inicializálón keresztül. Az alapértelmezett eset lesz az, amelyet a termelési kódhoz szeretne használni, és amikor egységtesztet ír, kicserélheti a lerakatot a modell változatával.

De talán gondolsz, mi lenne a típusokkal? A WebArticleRepository nem MockArticleRepository, tehát a fordító nem panaszkodik? Nos, ha nem használja a protokollt mint típust. Így tudatjuk a fordítót, mindent engedélyezünk, amíg megfelel a ArticleRepository protokollnak (amit mind a web, mind a MockArticleRepository tesz.).

A végleges kód így néz ki.

És az egységtesztében így cserélheted ki.

Most már teljes mértékben ellenőrizheti, hogy az adattár mely adatokat adja vissza.

Szuper bekapcsolás: generikus gyógyszerek

Ezt tovább tovább viheti generikus gyógyszerek felhasználásával. Ha gondolkodik, a legtöbb tároló mindig ugyanazokkal a műveletekkel rendelkezik

  1. szerezz mindent
  2. szerezz néhány dolgot
  3. illesszen be néhány dolgot
  4. törölje a dolgot
  5. frissítsen egy dolgot

Nos, az egyetlen, ami különbözik a „dolog” szóból, tehát ez kiváló jelölt lehet egy protokoll generikus termékekkel történő használatához. Lehet, hogy bonyolultnak hangzik, de valójában meglehetősen egyszerű.

Először átnevezzük a protokollt a Repository-ba, hogy ez még inkább… általános legyen.
És akkor eltávolítjuk az összes cikktípust és kicseréljük őket a varázslatos T.-re. De a T betű csak pótlást jelent ... bármi számára, amit mi akarunk. Csak T-et kell megjelölni a társított protokoll típusként.

Tehát most ezt a protokollt bármilyen modellobjektumunkhoz felhasználhatjuk.

1. Cikk tároló

A fordító a cikk típusához következtetni fogja a T típusát, mert a módszerek végrehajtásával meghatároztuk, hogy mi a T. Ebben az esetben egy cikk tárgya.

2. Felhasználói lerakat

Ez az.

Remélem, tetszett a cikk, és ha bármilyen kérdése vagy észrevétele van, kérdezze meg őket alább, vagy keressen fel nekem a Twitteren, és csevegjünk.