מאגרים שימושיים עם 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::שמור
• PostRepository::getById, מניפולציה של ישות וזימון PostRepository::שמור
• האתגר PostRepository::delete

פעולות כתיבה אינן משתמשות בשיטות אחזור. בפעולות קריאה משתמשים רק בשיטות get*. אם קראת על עקרון הפרדת ממשק (מִכְתָב I в מוצק), אז יתברר שהממשק שלנו גדול מדי ומבצע לפחות שתי תחומי אחריות שונים. הגיע הזמן לחלק אותו לשניים. שיטה getById הוא הכרחי בשניהם, אך ככל שהיישום נעשה מורכב יותר, ההטמעות שלו יהיו שונות. נראה את זה קצת מאוחר יותר. כתבתי על חוסר התועלת של חלק הכתיבה במאמר קודם, אז במאמר הזה אני פשוט אשכח מזה.

החלק של Read נראה לי לא כל כך חסר תועלת, מכיוון שאפילו עבור Eloquent עשויים להיות כאן כמה יישומים. איך קוראים לכיתה? פחית ReadPostRepository, אלא לתבנית Repository יש לו כבר מעט רלוונטיות. אתה יכול פשוט PostQueries:

<?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 רק מבקש יישום כלשהו PostsQueries ועובד עם זה. בספק שקישרנו PostQueries עם הכיתה EloquentPostQueries והמחלקה הזו תוחלף בבקר.

בואו נדמיין שהאפליקציה שלנו הפכה פופולרית מאוד. אלפי משתמשים בדקה פותחים את הדף עם הפרסומים האחרונים. גם הפרסומים הפופולריים ביותר נקראים לעתים קרובות מאוד. מסדי נתונים לא מטפלים בעומסים כאלה בצורה טובה, ולכן הם משתמשים בפתרון סטנדרטי - מטמון. בנוסף למסד הנתונים, תמונת מצב מסוימת מאוחסנת באחסון המותאם לפעולות מסוימות - נשלח למחשב או חוזר.

לוגיקה של מטמון היא בדרך כלל לא כל כך מסובכת, אבל הטמעתה ב- 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();
            });
    }

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

התעלם מהממשק Repository בקונסטרוקטור. מסיבה לא ידועה, הם החליטו לקרוא את הממשק לאחסון במטמון ב-Laravel בצורה זו.

בכיתה CachedPostQueries מיישמת מטמון בלבד. $this->cache->זכור בודק אם הערך הזה נמצא במטמון ואם לא, אז קורא להתקשרות חוזרת וכותב את הערך המוחזר למטמון. כל מה שנותר הוא ליישם את המחלקה הזו באפליקציה. אנחנו צריכים את כל המחלקות באפליקציה כדי לבקש יישום של הממשק PostQueries התחילו לקבל מופע של הכיתה 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);
    }
}

כל המשאלות שלי מתוארות באופן טבעי בספק. לפיכך, הטמענו מטמון עבור הבקשות שלנו רק על ידי כתיבת מחלקה אחת ושינוי תצורת הקונטיינר. שאר קוד האפליקציה לא השתנה.

כמובן, כדי ליישם מלא של מטמון, יש צורך גם ליישם ביטול תוקף כדי שהמאמר שנמחק לא יתקע באתר במשך זמן מה, אלא יימחק מיד. אבל אלו דברים מינוריים.

בשורה התחתונה: לא השתמשנו באחת, אלא בשתי תבניות. לִטעוֹם הפרדת אחריות שאילתת פקודה (CQRS) מציע להפריד לחלוטין בין פעולות קריאה וכתיבה ברמת הממשק. הגעתי אליו דרך עקרון הפרדת ממשק, מה שמרמז שאעשה מניפולציות מיומנות של דפוסים ועקרונות ואפיק אחד מהשני כמשפט :) כמובן שלא כל פרויקט צריך הפשטה כזו לבחירת ישויות, אבל אני אחלוק איתך את הטריק. בשלב הראשוני של היישום פיתוח, אתה יכול פשוט ליצור כיתה PostQueries עם היישום הרגיל באמצעות Eloquent:

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

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

כאשר מתעורר הצורך במטמון, בעזרת מהלך פשוט ניתן ליצור ממשק (או מחלקה אבסטרקטית) במקום המחלקה הזו PostQueries, העתק את היישום שלו לכיתה EloquentPostQueries ועבור לתכנית שתיארתי קודם. אין צורך לשנות את שאר קוד האפליקציה.

כל הטריקים האלה עם שיעורים, ממשקים, הזרקת תלות и CQRS מתואר בפירוט ב הספר שלי "ארכיטקטורה של יישומי אינטרנט מורכבים". יש גם פתרון לחידה מדוע כל הכיתות שלי בדוגמאות למאמר זה מסומנות כסופיות.

מקור: www.habr.com