სასარგებლო საცავი Eloquent-ით?

წინა კვირას დავწერე სტატია Eloquent პირებისთვის Repository-ის შაბლონის უსარგებლობის შესახებთუმცა, დამპირდა, რომ მითხრა, როგორ გამოვიყენო ნაწილობრივ თავის სასარგებლოდ. ამისათვის მე შევეცდები გავაანალიზო, თუ როგორ გამოიყენება ეს შაბლონი ჩვეულებრივ პროექტებში. საცავისთვის საჭირო მეთოდების მინიმალური ნაკრები:

<?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:: შენახვა
• PostRepository::getById, სუბიექტის მანიპულირება და გამოძახება PostRepository:: შენახვა
• გამოწვევა PostRepository:: წაშლა

ჩაწერის ოპერაციებში არ გამოიყენება გამოტანის მეთოდები. წაკითხვის ოპერაციებში გამოიყენება მხოლოდ get* მეთოდები. თუ წაიკითხავთ შესახებ ინტერფეისის სეგრეგაციის პრინციპი (წერილი I в ᲛᲧᲐᲠᲘ), მაშინ გაირკვევა, რომ ჩვენი ინტერფეისი ძალიან დიდია და ასრულებს მინიმუმ ორ განსხვავებულ პასუხისმგებლობას. დროა გავყოთ ორზე. მეთოდი getById აუცილებელია ორივეში, მაგრამ რაც უფრო რთული ხდება აპლიკაცია, მისი განხორციელება განსხვავდება. ამას ცოტა მოგვიანებით ვნახავთ. ჩაწერის ნაწილის უსარგებლობის შესახებ დავწერე წინა სტატიაში, ამიტომ ამ სტატიაში უბრალოდ დავივიწყებ მას.

წაკითხვის ნაწილი არც თუ ისე უსარგებლო მეჩვენება, რადგან 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 უბრალოდ ითხოვს განხორციელებას PostsQuery და მუშაობს მასთან. ჩვენ მიერ დაკავშირებულ პროვაიდერში პოსტშეკითხვები კლასთან ერთად 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-ში.

კლასი CachedPostQueries ახორციელებს მხოლოდ ქეშირებას. $this->cache-> დამახსოვრება ამოწმებს არის თუ არა ეს ჩანაწერი ქეშში და თუ არა, შემდეგ ურეკავს და წერს დაბრუნებულ მნიშვნელობას ქეშში. რჩება მხოლოდ ამ კლასის დანერგვა აპლიკაციაში. ჩვენ გვჭირდება ყველა კლასი, რომელიც აპლიკაციაში მოითხოვოს ინტერფეისის განხორციელება პოსტშეკითხვები დაიწყო კლასის ინსტანციის მიღება CachedPostQueries. თუმცა თვითონ CachedPostQueries კონსტრუქტორმა პარამეტრად უნდა მიიღოს კლასი 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);
    }
}

ყველა ჩემი სურვილი საკმაოდ ბუნებრივად არის აღწერილი პროვაიდერში. ამრიგად, ჩვენ განვახორციელეთ ჩვენი მოთხოვნების ქეშირება მხოლოდ ერთი კლასის დაწერით და კონტეინერის კონფიგურაციის შეცვლით. დანარჩენი განაცხადის კოდი არ შეცვლილა.

რა თქმა უნდა, ქეშირების სრულყოფილად განსახორციელებლად, ასევე აუცილებელია ბათილობის განხორციელება, რათა წაშლილი სტატია გარკვეული დროით არ დაკიდოს საიტზე, მაგრამ დაუყოვნებლივ წაიშალოს. მაგრამ ეს უმნიშვნელო რამ არის.

დედააზრი: ჩვენ გამოვიყენეთ არა ერთი, არამედ ორი შაბლონი. ნიმუში Command Query Responsibility Segregation (CQRS) გვთავაზობს სრულად განცალკევდეს წაკითხვისა და ჩაწერის ოპერაციები ინტერფეისის დონეზე. მე მასთან მივედი ინტერფეისის სეგრეგაციის პრინციპი, რაც გვაფიქრებინებს, რომ ოსტატურად ვამუშავებ შაბლონებს და პრინციპებს და ერთი მეორისგან თეორემას სახით გამოვიყვან :) რა თქმა უნდა, ყველა პროექტს არ სჭირდება ასეთი აბსტრაქცია სუბიექტების შერჩევისთვის, მაგრამ გაგიზიარებთ ხრიკს.აპლიკაციის საწყის ეტაპზე განვითარება, შეგიძლიათ უბრალოდ შექმნათ კლასი პოსტშეკითხვები ჩვეულებრივი განხორციელებით Eloquent-ის საშუალებით:

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

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

როდესაც ჩნდება ქეშირების საჭიროება, მარტივი ნაბიჯით შეგიძლიათ შექმნათ ინტერფეისი (ან აბსტრაქტული კლასი) ამ კლასის ნაცვლად. პოსტშეკითხვები, დააკოპირეთ მისი განხორციელება კლასში EloquentPostQueries და გადადით ადრე აღწერილ სქემაზე. დანარჩენი აპლიკაციის კოდი არ საჭიროებს შეცვლას.

ყველა ეს ხრიკი კლასებით, ინტერფეისებით, დამოკიდებულების ინექცია и CQRS დეტალურად აღწერილია ჩემი წიგნი "კომპლექსური ვებ აპლიკაციების არქიტექტურა". ასევე არსებობს გამოსავალი გამოცანიდან, თუ რატომ არის ამ სტატიის მაგალითებში ჩემი ყველა კლასი მონიშნული როგორც საბოლოო.

წყარო: www.habr.com