🥇Användbara repository med Eloquent?

Förra veckan skrev jag en artikel om onödigheten av mönstret Repository för Eloquent-entiteter, men jag lovade att berätta hur man delvis kan använda det med fördel. För detta kommer jag att försöka analysera hur detta mönster vanligtvis används i projekt. Minimiuppsättningen av metoder för ett repository:

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

Men i verkliga projekt, om det verkligen beslutas att använda repository, läggs det ofta till metoder för att välja poster:

<?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);
}

Dessa metoder skulle kunna implementeras genom Eloquent-scopes, men att överbelasta entitetsklasser med uppgifter för att hämta sig själva är ingen bra idé och att flytta detta ansvar till repository-klasser verkar logiskt. Är det så? Jag har avsiktligt visuellt delat denna gränssnitt i två delar. Den första delen av metoder kommer att användas i skrivoperationer.

Standard skrivoperationer är:

konstruera ett nytt objekt och anropa PostRepository::save
PostRepository::getById, manipulera med entiteten och anropa PostRepository::save
anropa PostRepository::delete

I skrivoperationer används inga urvalsmetoder. I läsoperationer används däremot endast metoder med get*. Om man läser om Interface Segregation Principle (bokstav I på SOLID), så blir det tydligt att vårt gränssnitt har blivit för stort och utför åtminstone två olika uppgifter. Det är dags att dela upp det i två. Metoden getById är nödvändig i båda, men när applikationen blir mer komplex kommer deras implementeringar att bli olika. Det kommer vi att se snart. Om onödigheten av skrivdelen skrev jag i den förra artikeln, så i denna kommer jag helt enkelt att glömma den.

Läsdelen verkar mig inte så onödig, eftersom även för Eloquent kan det finnas flera implementeringar här. Vad ska klassen heta? Man kan ReadPostRepository, men i förhållande till mönstret Repository har den redan lite att göra. Man kan helt enkelt PostQueries:

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

Dess implementering med hjälp av Eloquent är ganska enkel:

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();
    }
}

Gränssnittet bör kopplas till implementeringen, till exempel i AppServiceProvider:

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

Den här klassen är redan användbar. Den utför sitt ansvar och avlastar antingen kontroller eller entitetsklassen. I kontrollern kan den användas så här:

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

Metod PostsController::lastPosts ber bara om en implementering PostsQueries och arbetar med den. I leverantören kopplade vi PostQueries till klassen EloquentPostQueries och i kontrollern kommer denna klass att användas.

Låt oss föreställa oss att vår applikation har blivit mycket populär. Tusentals användare öppnar sidan med de senaste inläggen per minut. De mest populära inläggen läses också mycket ofta. Databaser klarar inte alltid av sådan belastning, så en standardlösning används — cache. Utöver databasen lagras en kopia av datan i ett magasin som är optimerat för vissa operationer — memcached eller redis.

Cachens logik är vanligtvis inte så komplicerad, men det är inte helt korrekt att implementera den i EloquentPostQueries (åtminstone på grund av Single Responsibility Principle). Det känns mycket mer naturligt att använda mönstret Decorator och implementera caching som dekorering av huvudåtgärden:

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();
            });
    }

    // andra metoder är praktiskt taget desamma
}

Ignorera gränssnittet Repository i konstruktören. Av någon oförklarlig anledning beslutades det att kalla gränssnittet för caching i Laravel.

Klassen CachedPostQueries implementerar endast caching. $this->cache->remember kontrollerar om det finns en post i cacheminnet och om inte, så anropas callback och värdet som returneras skrivs till cachen. Det kvarstår bara att integrera denna klass i applikationen. Vi måste se till att alla klasser som i applikationen begär en implementation av gränssnittet PostQueries börjar ta emot ett instans av klassen CachedPostQueries. Men själva CachedPostQueries som parameter i konstruktorn måste få klassen EloquentPostQueries, eftersom den inte kan fungera utan en "riktig" implementation. Ändra AppServiceProvider:

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

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

Alla mina önskemål beskrivs ganska naturligt i providern. Därmed har vi implementerat caching för våra förfrågningar genom att bara skriva en klass och ändra konfigurationen av containern. Koden för resten av applikationen har inte ändrats.

Självklart, för en fullständig implementation av caching är det också nödvändigt att implementera invalidation, så att den borttagna artikeln inte hänger kvar på webbplatsen en stund utan tas bort direkt. Men det är redan småsaker.

Sammanfattning: vi använde inte en utan hela två mönster. Mönstret Command Query Responsibility Segregation (CQRS) erbjuder att helt separera läs- och skrivoperationer på gränssnittens nivå. Jag kom till det via Interface Segregation Principle, vilket indikerar att jag kunnigt manipulerar mönster och principer och härleder ett ur ett annat som en teorem 🙂 Självklart är inte varje projekt i behov av en sådan abstraktion för entitetsförfrågningar, men jag kommer att dela med mig av ett trick. I det inledande skedet av applikationsutvecklingen kan man helt enkelt skapa en klass PostQueries med en vanlig implementation genom Eloquent:

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

    // andra metoder
}

När behovet av caching uppstår kan man enkelt skapa ett gränssnitt (eller abstrakt klass) istället för denna klass PostQueries, kopiera dess implementation till klassen EloquentPostQueries och övergå till schemat som jag beskrev tidigare. Den övriga koden i applikationen behöver inte ändras.

Alla dessa trick med klasser, gränssnitt, Beroendeinjektion och CQRS beskrivs i detalj i min bok "Arkitektur för komplexa webbapplikationer". Där finns gåtan till varför alla mina klasser i exemplen till den här artikeln är märkta som final.

Källa: habr.com

Nyttiga repositorier med Eloquent?