Полезни репозитории с Eloquent?

Миналата седмица написах статия за безполезността на шаблона Репозиторий за Eloquent същности, но обещах да разкажа как може частично да се използва с полза. За това ще се опитам да анализирам как обикновено използват този шаблон в проектите. Минимално необходимият набор от методи за репозиторий:

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

Въпреки това, в реалните проекти, ако е решено да се използват репозитории, в тях често се добавят методи за извличане на записи:

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

Тези методи биха могли да се реализират чрез Eloquent scopes, но натоварването на класовете същности с отговорности за извличането на самите себе си не е най-добрата идея и прехвърлянето на тази отговорност в класовете на репозиторията изглежда логично. Така ли е? Специално визуално разделих този интерфейс на две части. Първата част от методите ще бъде използвана в операциите за запис.

Стандартната операция за запис е:

• конструиране на нов обект и извикване на PostRepository::save
• PostRepository::getById, манипулации със същността и извикване на PostRepository::save
• извикване PostRepository::delete

В операциите за запис няма използване на методи за избор. В операциите за четене обаче се използват само методи get*. Ако се запознаете с Interface Segregation Principle (буква I в SOLID), ще стане ясно, че нашият интерфейс се оказа твърде голям и изпълнява поне две различни отговорности. Време е да го разделим на две. Методът getById е необходим в двете, но при усложняване на приложението неговите реализации ще бъдат различни. Това ще видим малко по-късно. За безполезността на частта за запис писах в миналата статия, така че в тази просто ще забравя за нея.

Частта за четене обаче ми се струва не толкова безполезна, тъй като дори за Eloquent тук може да има няколко реализации. Как да наречем класа? Може да се нарече ReadPostRepository, но към шаблона Repository той вече няма много отношение. Може просто да бъде PostQueries:

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

Неговата реализация с помощта на Eloquent е доста проста:

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

Интерфейсът трябва да бъде свързан с реализация, например в AppServiceProvider:

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

Този клас вече е полезен. Той реализира своята отговорност, освобождавайки или контролерите, или класа на съществото. В контролера той може да бъде използван така:

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

Метод PostsController::lastPosts просто иска някаква реализация за себе си PostsQueries и работи с нея. В провайдера ние свързахме PostQueries с класа EloquentPostQueries и в контролера ще бъде подставен този клас.

Нека си представим, че нашето приложение стана много популярно. Хиляди потребители в минута отварят страницата с последните публикации. Най-популярните публикации също се четат много често. Базите данни не се справят добре с такива натоварвания, затова се използва стандартното решение — кеш. Освен базата данни, някакъв отпечатък на данни се съхранява в хранилище, оптимизирано за определени операции — memcached или redis.

Логиката на кеширането обикновено не е толкова сложна, но реализирането й в EloquentPostQueries не е много правилно (поне поради Принципа на единствената отговорност). Много по-естествено е да се използва шаблонът Декоратор и да се реализира кеширането като декориране на основното действие:

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

    // другите методи практически са същите
}

Не обръщайте внимание на интерфейса Repository в конструктора. По непонятна причина така решиха да нарекат интерфейса за кеширане в Laravel.

Клас CachedPostQueries реализира само кеширане. $this->cache->remember проверява дали тази запись не е в кеша и ако не е, извиква callback и записва в кеша върнатата стойност. Остава само да внедрим този клас в приложението. Нужно е всички класове, които в приложението искат реализация на интерфейса PostQueries да започнат да получават екземпляр на класа CachedPostQueries. Обаче самият CachedPostQueries като параметър в конструктора трябва да получи класа EloquentPostQueries, тъй като не може да работи без "истинска" реализация. Променяме AppServiceProvider:

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

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

Всички мои желания доста естествено се описват в провайдера. Така реализирахме кеширане за нашите заявки само като написахме един клас и променихме конфигурацията на контейнера. Кодът на останалата част от приложението не се е променил.

Разбира се, за пълноценно реализиране на кеширането е необходимо да се реализира и инвалидация, за да не остава премахнатата статия на сайта още известно време, а да бъде премахната веднага. Но това вече са дреболии.

Резултат: използвахме не един, а цели два шаблона. Шаблонът Command Query Responsibility Segregation (CQRS) предлага напълно да се разделят операциите за четене и запис на ниво интерфейси. Достигнах до него чрез Interface Segregation Principle, което показва, че умея да манипулирам шаблоните и принципите и извеждам едно от друго като теорема 🙂 Разбира се, не на всеки проект е необходима такава абстракция за извличане на същности, но ще споделя с вас трик. На началния етап на разработката на приложението може просто да създадете клас PostQueries с обикновена реализация чрез Eloquent:

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

    // други методи
}

Когато възникне необходимост от кеширане, с леко движение можете да създадете интерфейс (или абстрактен клас) на мястото на този клас PostQueries, да копирате неговата реализация в класа EloquentPostQueries и да преминете към схемата, описана от мен по-рано. Останалият код на приложението не е необходимо да се променя.

Всички тези трикове с класовете, интерфейсите, Dependency Injection и CQRS са подробно описани в моят труд „Архитектура на сложни уеб приложения“. Там е разгадаването на загадката защо всички мои класове в примерите на тази статия са обозначени като финални.

Източник: habr.com