एलोक्वेंट के साथ उपयोगी रिपॉजिटरी?

पिछले सप्ताह मैंने लिखा था एलोकेंट संस्थाओं के लिए रिपॉजिटरी टेम्पलेट की बेकारता के बारे में लेखहालाँकि, उन्होंने मुझे यह बताने का वादा किया कि मैं इसे अपने लाभ के लिए आंशिक रूप से कैसे उपयोग कर सकता हूँ। ऐसा करने के लिए, मैं यह विश्लेषण करने का प्रयास करूंगा कि इस टेम्पलेट का उपयोग आमतौर पर परियोजनाओं में कैसे किया जाता है। रिपॉजिटरी के लिए विधियों का न्यूनतम आवश्यक सेट:

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

इन तरीकों को एलोकेंट स्कोप के माध्यम से कार्यान्वित किया जा सकता है, लेकिन खुद को लाने की ज़िम्मेदारी के साथ इकाई वर्गों को ओवरलोड करना सबसे अच्छा विचार नहीं है, और इस ज़िम्मेदारी को रिपोजिटरी कक्षाओं में ले जाना तर्कसंगत लगता है। क्या ऐसा है? मैंने विशेष रूप से इस इंटरफ़ेस को दृश्य रूप से दो भागों में विभाजित किया है। विधियों के पहले भाग का उपयोग लेखन कार्यों में किया जाएगा।

मानक लेखन ऑपरेशन है:

• एक नई वस्तु और चुनौती का निर्माण पोस्टरिपोजिटरी::सहेजें
• PostRepository::getById, इकाई में हेरफेर और सम्मन पोस्टरिपोजिटरी::सहेजें
• कॉल पोस्टरिपोजिटरी::हटाएँ

लिखने के संचालन में फ़ेच विधियों का उपयोग नहीं किया जाता है। रीड ऑपरेशंस में, केवल get* विधियों का उपयोग किया जाता है। अगर आप इसके बारे में पढ़ते हैं इंटरफ़ेस पृथक्करण सिद्धांत (पत्र I в ठोस), तो यह स्पष्ट हो जाएगा कि हमारा इंटरफ़ेस बहुत बड़ा है और कम से कम दो अलग-अलग जिम्मेदारियाँ निभाता है। इसे दो से विभाजित करने का समय आ गया है। तरीका getById दोनों में आवश्यक है, लेकिन जैसे-जैसे अनुप्रयोग अधिक जटिल होता जाएगा, इसका कार्यान्वयन अलग-अलग होगा। इसे हम थोड़ी देर बाद देखेंगे. मैंने पिछले लेख में लेखन भाग की बेकारता के बारे में लिखा था, इसलिए इस लेख में मैं इसके बारे में भूल जाऊंगा।

मुझे लगता है कि रीड भाग इतना बेकार नहीं है, क्योंकि यहां एलोक्वेंट के लिए भी कई कार्यान्वयन हो सकते हैं। क्लास का नाम क्या रखें? कर सकना ReadPostRepository, लेकिन टेम्पलेट के लिए कोष उसकी पहले से ही बहुत कम प्रासंगिकता है। आप बस कर सकते हैं पोस्टक्वेरीज़:

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

एलोक्वेंट के साथ इसे लागू करना काफी सरल है:

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

इंटरफ़ेस को कार्यान्वयन से संबद्ध होना चाहिए, उदाहरण के लिए ऐप सेवा प्रदाता:

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

विधि पोस्टकंट्रोलर::अंतिमपोस्ट बस कुछ कार्यान्वयन के लिए पूछ रहा हूँ पोस्ट प्रश्न और इसके साथ काम करता है. जिस प्रदाता से हमने लिंक किया है पोस्टक्वेरीज़ कक्षा के साथ एलोक्वेंटपोस्टक्वेरीज़ और इस वर्ग को नियंत्रक में प्रतिस्थापित कर दिया जाएगा।

आइए कल्पना करें कि हमारा एप्लिकेशन बहुत लोकप्रिय हो गया है। प्रति मिनट हजारों उपयोगकर्ता नवीनतम प्रकाशनों वाला पृष्ठ खोलते हैं। सर्वाधिक लोकप्रिय प्रकाशन भी अक्सर पढ़े जाते हैं। डेटाबेस ऐसे लोड को बहुत अच्छी तरह से संभाल नहीं पाते हैं, इसलिए वे एक मानक समाधान - कैश का उपयोग करते हैं। डेटाबेस के अलावा, एक निश्चित डेटा स्नैपशॉट को कुछ कार्यों के लिए अनुकूलित स्टोरेज में संग्रहीत किया जाता है - memcached या redis.

कैशिंग तर्क आमतौर पर इतना जटिल नहीं है, लेकिन इसे एलोक्वेंटपोस्टक्वेरीज़ में लागू करना बहुत सही नहीं है (यदि केवल इसलिए) एकल जिम्मेदारी सिद्धांत). टेम्पलेट का उपयोग करना अधिक स्वाभाविक है डेकोरेटर और मुख्य क्रिया के लिए कैशिंग को सजावट के रूप में लागू करें:

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

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

इंटरफ़ेस पर ध्यान न दें कोष कंस्ट्रक्टर में. किसी अज्ञात कारण से, उन्होंने लारवेल में कैशिंग के लिए इंटरफ़ेस को इस तरह नाम देने का निर्णय लिया।

वर्ग कैश्डपोस्टक्वेरीज़ केवल कैशिंग लागू करता है। $यह->कैश->याद रखें जाँचता है कि क्या यह प्रविष्टि कैश में है और यदि नहीं, तो कॉलबैक कॉल करता है और लौटाए गए मान को कैश में लिखता है। जो कुछ बचा है वह इस वर्ग को एप्लिकेशन में लागू करना है। इंटरफ़ेस के कार्यान्वयन का अनुरोध करने के लिए हमें एप्लिकेशन में मौजूद सभी वर्गों की आवश्यकता है पोस्टक्वेरीज़ कक्षा का एक उदाहरण प्राप्त करना शुरू हुआ कैश्डपोस्टक्वेरीज़. हालाँकि, वह स्व कैश्डपोस्टक्वेरीज़ कंस्ट्रक्टर को एक पैरामीटर के रूप में एक क्लास प्राप्त करनी होगी एलोक्वेंटपोस्टक्वेरीज़चूँकि यह "वास्तविक" कार्यान्वयन के बिना काम नहीं कर सकता। हम बदलते हैं ऐप सेवा प्रदाता:

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

मेरी सभी इच्छाएँ प्रदाता में स्वाभाविक रूप से वर्णित हैं। इस प्रकार, हमने केवल एक वर्ग लिखकर और कंटेनर कॉन्फ़िगरेशन को बदलकर अपने अनुरोधों के लिए कैशिंग लागू की। शेष एप्लिकेशन कोड नहीं बदला है.

बेशक, कैशिंग को पूरी तरह से लागू करने के लिए अमान्यकरण को लागू करना भी आवश्यक है ताकि हटाया गया लेख कुछ समय के लिए साइट पर लटका न रहे, बल्कि तुरंत हटा दिया जाए। लेकिन ये छोटी-मोटी बातें हैं.

निचली पंक्ति: हमने एक नहीं, बल्कि दो टेम्पलेट्स का उपयोग किया। नमूना कमांड क्वेरी उत्तरदायित्व पृथक्करण (सीक्यूआरएस) इंटरफ़ेस स्तर पर पढ़ने और लिखने के संचालन को पूरी तरह से अलग करने का प्रस्ताव है। मैं उसके माध्यम से आया था इंटरफ़ेस पृथक्करण सिद्धांत, जो सुझाव देता है कि मैं कुशलता से पैटर्न और सिद्धांतों में हेरफेर करता हूं और एक को दूसरे से प्रमेय के रूप में प्राप्त करता हूं :) बेशक, हर परियोजना को संस्थाओं के चयन के लिए इस तरह के अमूर्त की आवश्यकता नहीं है, लेकिन मैं आपके साथ चाल साझा करूंगा। आवेदन के प्रारंभिक चरण में विकास, आप बस एक कक्षा बना सकते हैं पोस्टक्वेरीज़ एलोक्वेंट के माध्यम से सामान्य कार्यान्वयन के साथ:

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

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

जब कैशिंग की आवश्यकता उत्पन्न होती है, तो एक साधारण कदम से आप इस वर्ग के स्थान पर एक इंटरफ़ेस (या अमूर्त वर्ग) बना सकते हैं पोस्टक्वेरीज़, इसके कार्यान्वयन को कक्षा में कॉपी करें एलोक्वेंटपोस्टक्वेरीज़ और उस योजना पर जाएँ जिसका मैंने पहले वर्णन किया था। बाकी एप्लिकेशन कोड को बदलने की जरूरत नहीं है।

कक्षाओं, इंटरफ़ेस के साथ ये सभी तरकीबें, निर्भरता अन्तःक्षेपण и सीक्यूआरएस में विस्तार से वर्णित है मेरी पुस्तक "कॉम्प्लेक्स वेब एप्लिकेशन का आर्किटेक्चर". इस पहेली का भी एक समाधान है कि इस लेख के उदाहरणों में मेरी सभी कक्षाओं को अंतिम के रूप में क्यों चिह्नित किया गया है।

स्रोत: www.habr.com