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

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

<?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 को कॉल करें :: सहेजें
• PostRepository :: getById , इकाई जोड़तोड़ और PostRepository :: save
• कॉल PostRepository :: हटाएं

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

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

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

इंटरफ़ेस कार्यान्वयन के साथ जुड़ा होना चाहिए, उदाहरण के लिए 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(), ]); } } 

पोस्टकंट्रोलर :: lastPosts विधि केवल पोस्टक्वेरी के कुछ कार्यान्वयन के लिए खुद से पूछती है और इसके साथ काम करती है। प्रदाता में, हम पोस्टक्वेरीज़ को एलक्वेंटपॉइंटक्वायरीज वर्ग के साथ जोड़ते हैं और इस वर्ग को नियंत्रक में प्रतिस्थापित किया जाएगा।

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

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

 <?php use Illuminate\Contracts\Cache\Repository; 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(); }); } //      } 

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

कैश्डपोस्टक्वायरीज वर्ग केवल कैशिंग लागू करता है। $ यह-> कैश-> यह देखने के लिए चेक याद रखें कि क्या दी गई प्रविष्टि कैश में है और यदि नहीं, तो यह कॉलबैक कहता है और कैश को लौटा मूल्य लिखता है। यह केवल आवेदन में इस वर्ग को लागू करने के लिए बनी हुई है। हमें उन सभी वर्गों की आवश्यकता है जो एप्लिकेशन में कैश्डपोस्टक्वायरीज वर्ग का एक उदाहरण प्राप्त करने के लिए पोस्टक्वेरीज़ इंटरफ़ेस के कार्यान्वयन के लिए पूछते हैं । हालांकि, कैश्डपोस्टक्वायरीज को खुद को कंस्ट्रक्टर में एक पैरामीटर के रूप में एलोक्वेंटपोस्टक्वायरीज वर्ग प्राप्त करना चाहिए, क्योंकि यह "वास्तविक" कार्यान्वयन के बिना काम नहीं कर सकता है। 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) टेम्प्लेट इंटरफ़ेस स्तर पर पढ़ने और लिखने के संचालन का पूर्ण पृथक्करण प्रदान करता है। मैं इंटरफ़ेस अलगाव सिद्धांत के माध्यम से उनके पास आया, जिसका अर्थ है कि मैं कुशलता से टेम्पलेट्स और सिद्धांतों में हेरफेर करता हूं और एक को प्रमेय के रूप में दूसरे से अलग करता हूं :) बेशक, प्रत्येक परियोजना को इकाई नमूनों पर इस तरह के अमूर्त की आवश्यकता नहीं है, लेकिन मैं आपके साथ ध्यान केंद्रित करूंगा। अनुप्रयोग विकास के प्रारंभिक चरण में, आप केवल एलक्वेंट के माध्यम से एक नियमित कार्यान्वयन के साथ पोस्टक्वेरीज़ क्लास बना सकते हैं:

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

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

हालाँकि, समान पोस्ट संस्थाओं का उपयोग करने के साथ एक समस्या बनी हुई है जो डेटा को संशोधित कर सकती है। यह बिल्कुल CQRS नहीं है।

पोस्टक्वेरीज़ से पोस्ट इकाई प्राप्त करने के लिए कोई भी परेशान नहीं करता है, इसे संशोधित करें और परिवर्तनों को एक सरल -> सहेजें () के साथ सहेजें । और यह काम करेगा।
थोड़ी देर के बाद, टीम डेटाबेस में मास्टर-स्लेव प्रतिकृति में बदल जाएगी और पोस्टक्वेरीज़ रीड- रेप्लिका के साथ काम करेगी। पढ़ी गई प्रतिकृतियों पर लिखने का कार्य आमतौर पर अवरुद्ध होता है। त्रुटि खुल जाएगी, लेकिन आपको ऐसे सभी जाम को ठीक करने के लिए कड़ी मेहनत करनी होगी।

स्पष्ट समाधान पढ़ने और लिखने के हिस्सों को पूरी तरह से अलग करना है। आप एलोकेंट का उपयोग करना जारी रख सकते हैं, लेकिन केवल-पढ़ने के लिए मॉडल के लिए एक वर्ग बनाकर। उदाहरण: https://github.com/adelf/freelance-example/blob/master/app/ReadModels/ReadModel.php सभी डेटा संशोधन संचालन अवरुद्ध हैं। एक नया मॉडल बनाएँ, उदाहरण के लिए ReadPost (आप पोस्ट छोड़ सकते हैं, लेकिन इसे किसी अन्य नामस्थान पर ले जा सकते हैं):

 <?php final class ReadPost extends ReadModel { protected $table = 'posts'; } interface PostQueries { public function getById($id): ReadPost; } 

ऐसे मॉडल को केवल पढ़ा जा सकता है और सुरक्षित रूप से कैश किया जा सकता है।

एक अन्य विकल्प: एलोकेंट को त्याग दें। इसके कई कारण हो सकते हैं:

• सभी तालिका फ़ील्ड लगभग आवश्यक नहीं हैं। LastPosts अनुरोध के लिए, केवल आईडी , शीर्षक और, उदाहरण के लिए, प्रकाशित_ट फ़ील्ड आमतौर पर आवश्यक हैं। प्रकाशनों के कुछ भारी पाठों का अनुरोध केवल डेटाबेस या कैश पर एक अनावश्यक भार देगा। वाक्पटु केवल आवश्यक फ़ील्ड का चयन कर सकता है, लेकिन यह सब बहुत निहित है। पोस्टक्वेरीज़ ग्राहकों को ठीक से पता नहीं होता है कि कार्यान्वयन के बिना कौन से फ़ील्ड चुने गए हैं।
• कैशिंग डिफ़ॉल्ट रूप से क्रमांकन का उपयोग करता है। क्रमबद्ध रूप में सुयोग्य वर्ग बहुत अधिक स्थान लेते हैं। यदि साधारण संस्थाओं के लिए यह विशेष रूप से ध्यान देने योग्य नहीं है, तो रिश्तों के साथ जटिल संस्थाओं के लिए यह एक समस्या बन जाती है (आप कैश से मेगाबाइट आकार की वस्तुओं को कैसे खींचते हैं?)। एक परियोजना में, कैश में सार्वजनिक क्षेत्रों के साथ एक साधारण वर्ग ने एलोकेंट विकल्प की तुलना में 10 गुना कम जगह ली (बहुत छोटी उप-नृतियां थीं)। कैशिंग करते समय आप केवल विशेषताओं को कैश कर सकते हैं, लेकिन यह प्रक्रिया को बहुत जटिल करेगा।

यह कैसे दिख सकता है इसका एक सरल उदाहरण:

 <?php final class PostHeader { public int $id; public string $title; public DateTime $publishedAt; } final class Post { public int $id; public string $title; public string $text; public DateTime $publishedAt; } interface PostQueries { public function getById($id): Post; /** * @return PostHeader[] */ public function getLastPosts(); /** * @return PostHeader[] */ public function getTopPosts(); /** * @var int $userId * @return PostHeader[] */ public function getUserPosts($userId); } 

बेशक, यह सब तर्क की एक जंगली अतिसुविधा की तरह लगता है। "एलोकेंट स्कोप ले लो और सबकुछ ठीक हो जाएगा। यह सब क्यों आया?" सरल परियोजनाओं के लिए, यह सही है। स्कोप को पुन: स्थापित करने की कोई आवश्यकता नहीं है। लेकिन जब परियोजना बड़ी होती है और कई डेवलपर्स विकास में शामिल होते हैं, जो अक्सर बदलते हैं (वे छोड़ देते हैं और नए आते हैं), खेल के नियम थोड़े अलग हो जाते हैं। कोड को सुरक्षित रूप से लिखा जाना चाहिए ताकि कुछ वर्षों के बाद नया डेवलपर कुछ गलत न कर सके। बेशक, ऐसी संभावना को पूरी तरह से बाहर करना असंभव है, लेकिन इसकी संभावना को कम करना आवश्यक है। इसके अलावा, यह एक सामान्य प्रणाली अपघटन है। आप कैश को एक निश्चित "कैशिंग मॉड्यूल" में अमान्य करने के लिए सभी कैशिंग सज्जाकार और कक्षाएं एकत्र कर सकते हैं, इस प्रकार कैशिंग के बारे में जानकारी के बाकी आवेदन को बचा सकते हैं। मुझे कैश रिक्वेस्ट से घिरे बड़े रिक्वेस्ट के जरिए हंगामा करना पड़ा। यह रास्ते में हो जाता है। विशेष रूप से यदि कैशिंग लॉजिक सरल नहीं है जैसा कि ऊपर वर्णित है।