Kasulikud Eloquenti reposiitorid?

Eelmisel nädalal kirjutasin artikli Eloquent objektide jaoks mõttetu Repository malli kohta, kuid lubasin rääkida, kuidas seda osaliselt kasulikult kasutada. Selleks püüan analüüsida, kuidas seda malli projektides tavaliselt kasutatakse. Minimiaalne vajalik meetodite komplekt repozitooriumi jaoks:

<php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);
}

Kuid reaalsetes projektides, kui repozitooriume otsustatakse kasutada, lisatakse neisse sageli meetodeid andmete valimiseks:

<php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);

    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Need meetodid võiks teostada läbi Eloquent skoopide, kuid klasside koormamine iseenda valikute tegemisega ei ole parim lahendus ja selle vastutuse viimine repozitooriumi klassidesse tundub loogiline. Kas see on tõsi? Olen spetsiaalselt visuaalselt jaganud selle liidese kaheks osaks. Esimene osa meetoditest kasutatakse salvestamisoperatsioonides.

Standardsed salvestamisoperatsioonid on:

• uue objekti konstrueerimine ja üleskutse PostRepository::save
• PostRepository::getById, manipulatsioonid objekti ja üleskutse PostRepository::save
• üleskutse PostRepository::delete

Salvestamisoperatsioonides ei kasutata valiku meetodeid. Lugemise operatsioonides kasutatakse aga ainult meetodeid get*. Kui lugeda Interface Segregation Principle (tähe I ja SOLID), siis on selge, et meie liides on liiga suur ja täidab vähemalt kahte erinevat kohustust. On aeg jagada see kaheks. Meetod getById on vajalik mõlemas, kuid rakendusi keerukama rakenduse puhul on need erinevad. Seda näeme veidi hiljem. Kirjutasin eelmisel artiklil write-osa mõttetusest, nii et selles artiklis unustan selle lihtsalt.

Loetud osa ei tundu mulle siiski nii kasutu, kuna isegi Eloquent'i puhul võib siin olla mitu rakendust. Kuidas klassi nimetada? Võib-olla ReadPostRepository, kuid malliga Repository on see juba vähe seotud. Võib lihtsalt nimetada PostQueries:

<php
interface PostQueries
{
    public function getById($id): Post;
    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Selle teostamine Eloquent'i abil on üsna lihtne:

limit(/*some limit*/)
            ->get();
    }
    /**
    * @return Post[] | Collection
    */
    public function getTopPosts()
    {
        return Post::orderBy('rating', 'desc')
            ->limit(/*some limit*/)
            ->get();
    }

    /**
    * @param int $userId
    * @return Post[] | Collection
    */
    public function getUserPosts($userId)
    {
        return Post::whereUserId($userId)
            ->orderBy('created_at', 'desc')
            ->get();
    }
}

Liides peab olema seotud rakendusega, näiteks AppServiceProvider:

app->bind(PostQueries::class, 
            EloquentPostQueries::class);
    }
}

See klass on juba kasulik. See täidab oma ülesande, leevendades kas kontrollerite või entiteedi klassi koormust. Kontrolleris saab seda kasutada järgmiselt:

$postQueries->getLastPosts(),
        ]);
    }
} 

Meetod PostsController::lastPosts lihtsalt küsib endale mõnda teostust PostsQueries ja töötab selle kallal. Pakkujas seostasime PostQueries klassi EloquentPostQueries ja kontrolleris asendatakse see klass.

Kujutage ette, et meie rakendus on saanud väga populaarseks. Tuhanded kasutajad avavad minutis viimaste postituste lehte. Kõige populaarsemaid postitusi loetakse samuti väga sageli. Andmebaasid ei suuda selliste koormustega hästi toime tulla, seega kasutatakse standardlahendust — vahemälu. Lisaks andmebaasile hoitakse andmete koopiaid teatud operatsioonide jaoks optimeeritud salvestuses — memcached või redis.

Vahemälustamise loogika ei ole tavaliselt kuigi keeruline, kuid selle rakendamine EloquentPostQueries-s ei ole õigete põhjuste tõttu väga õige (vähemalt sellepärast, et Kandidaadi Üksiku Vastutuse Printsiip). Loomulikult on loogilisem kasutada kaunistamismustrit Dekoraator ja rakendada vahemällu salvestamine kui põhitegevuse kaunistamine:

base = $base;
        $this->cache = $cache;
    }

    /**
    * @return Post[] | Collection
    */
    public function getLastPosts()
    {
        return $this->cache->remember('last_posts', 
            self::LASTS_DURATION, 
            function(){
                return $this->base->getLastPosts();
            });
    }

    // muud meetodid on praktiliselt samad
}

Ärge muretsege liidese pärast Repository ehitajas. Ilmselt on mingil põhjusel otsustatud nimetada Laravelis vahemälu liidest nii.

Klass CachedPostQueries rakendab ainult vahemälu. $this->cache->remember kontrollib, kas antud kirje on vahemälus ja kui seda ei ole, käivitab ta tagasikutse ning salvestab vahemällu tagastatud väärtuse. Jäänud on vaid see klass rakendusse integreerida. Peame tagama, et kõik klassid, mis rakenduses küsivad liidese rakendust PostQueries hakaksid saama klassi eksemplari CachedPostQueries. Kuid ise CachedPostQueries peab konstruktorisse saama klassi EloquentPostQueries, kuna tal ei ole võimalik töötada ilma "päris" rakenduse. Muudame AppServiceProvider:

app->bind(PostQueries::class, 
            CachedPostQueries::class);

        $this->app->when(CachedPostQueries::class)
            ->needs(PostQueries::class)
            ->give(EloquentPostQueries::class);
    }
}

Kõik minu soovid on üsna loomulikult kirjeldatud pakkujas. Nii oleme realiseerinud vahemälu meie päringutele, kirjutades vaid ühe klassi ja muutes konteineri konfiguratsiooni. Ülejäänud rakenduse kood ei ole muutunud.

Muidugi, et vahemälu täielikult rakendada, tuleb veel teostada kehtetuks tunnistamine, et eemaldatud artikkel ei jääks veebilehele veel mõneks ajaks, vaid kustutataks kohe. Kuid see on juba pisiasjad.

Kokkuvõte: kasutasime mitte ühte, vaid lausa kahte malli. Mall Command Query Responsibility Segregation (CQRS) soovitab täielikult eristada lugemise ja kirjutamise toimingud liidese tasemel. Ma jõudsin sellele läbi Interface Segregation Principle, mis näitab, et ma oskan šabloone ja põhimõtteid osavalt manipuleerida ning tuua ühe teisest nagu teoreemi 🙂 Muidugi ei vaja iga projekt sellist abstraktsiooni olendite valikute jaoks, kuid jagan teiega näpunäidet. Rakenduse arendamise algfaasis saate lihtsalt luua klassi PostQueries tavalise rakendusega läbi Eloquent:

<?php
final class PostQueries
{
    public function getById($id): Post
    {
        return Post::findOrFail($id);
    }

    // teised meetodid
}

Kui vahemälu rakendamine muutub vajalikuks, on kerge käeliigutusega luua liides (või abstraktne klass) selle klassi kohale PostQueries, selle rakendus kopeerida klassi EloquentPostQueries ja liikuda skeemile, mida ma varem kirjeldasin. Ülejäänud rakenduse koodi ei ole vaja muuta.

Kõik need nipid klasside, liideste, Sõltuvuse süstimine ja CQRS on põhjalikult kirjeldatud minu raamatus "Ahnne web-rakenduste arhitektuur". Seal see vastus, miks kõik minu klassid selles artiklis on märgitud kui final.

Allikas: habr.com