Полезни хранилища с Eloquent?

Миналата седмица писах статия за безполезността на шаблона Repository за обекти на 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, но претоварването на класовете обекти с отговорността да се извличат сами не е най-добрата идея и преместването на тази отговорност към класове хранилища изглежда логично. Така е? Специално визуално разделих този интерфейс на две части. Първата част от методите ще се използва при операции за запис.

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

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

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

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

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

Прилагането му с Eloquent е доста просто:

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

    /**
    * @return Post[] | Collection
    */
    public function getLastPosts()
    {
        return Post::orderBy('created_at', 'desc')
            ->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:

<?php
final class AppServiceProvider extends ServiceProvider 
{
    public function register()
    {
        $this->app->bind(PostQueries::class, 
            EloquentPostQueries::class);
    }
}

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

<?php
final class PostsController extends Controller
{
    public function lastPosts(PostQueries $postQueries)
    {
        return view('posts.last', [
            'posts' => $postQueries->getLastPosts(),
        ]);
    }
} 

метод PostsController::lastPosts просто моля за някакво внедряване Заявки за публикации и работи с него. В доставчика, който свързахме Постзаявки с класа EloquentPostQueries и този клас ще бъде заменен в контролера.

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

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

<?php
use IlluminateContractsCacheRepository;

final class CachedPostQueries implements PostQueries
{
    const LASTS_DURATION = 10;

    /** @var PostQueries */
    private $base;

    /** @var Repository */
    private $cache;

    public function __construct(
        PostQueries $base, Repository $cache) 
    {
        $this->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();
            });
    }

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

Игнорирайте интерфейса хранилище в конструктора. По някаква неизвестна причина те решиха да кръстят интерфейса за кеширане в Laravel по този начин.

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

<?php
final class AppServiceProvider extends ServiceProvider 
{
    public function register()
    {
        $this->app->bind(PostQueries::class, 
            CachedPostQueries::class);

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

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

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

В крайна сметка: използвахме не един, а два шаблона. проба Разделяне на отговорността за запитване на команди (CQRS) предлага напълно разделяне на операциите за четене и запис на ниво интерфейс. Стигнах до него чрез Принцип на разделяне на интерфейса, което предполага, че умело манипулирам шаблони и принципи и извеждам един от друг като теорема :) Разбира се, не всеки проект се нуждае от такава абстракция за избор на обекти, но ще споделя трика с вас.В началния етап на приложение развитие, можете просто да създадете клас Постзаявки с обичайната реализация чрез Eloquent:

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

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

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

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

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