स्विफ्ट में रिपोजिटरी डिजाइन पैटर्न

अपने मॉडलों को क्वेरी करने का एक साफ तरीका

यह किस समस्या का हल है?

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

दृश्य को स्केच करना।

मान लें कि आपके पास कुछ कोड है जो API से डेटा प्राप्त करता है और इसे मॉडल ऑब्जेक्ट में मैप करता है। इस उदाहरण में, मैं एक सर्वर से लेखों की एक सूची लाऊंगा।

यह थोडा फनी लग सकता है, लेकिन यह सिर्फ RxSwift है, जो Moya का उपयोग नेटवर्किंग अमूर्त परत के रूप में करता है, लेकिन यह वास्तव में क्या हो रहा है यह समझने के लिए मायने नहीं रखता है। जिस तरह से आप अपने डेटा को पुनः प्राप्त करते हैं वह पूरी तरह से आपके ऊपर है।

इस कोड का टुकड़ा करता है

  1. सर्वर के लिए एक अनुरोध प्राप्त करें
  2. JSON को आलेख ऑब्जेक्ट्स की एक सरणी में मैप करता है
  3. जब सब काम पूरा हो जाता है तो बंद को बुलाया जाता है।

हमें एक भंडार की आवश्यकता क्यों है?

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

ठीक है ... लेकिन एक रिपॉजिटरी ऑब्जेक्ट कब उपयोग करने के लिए सुविधाजनक है?
मान लीजिए कि आपका कोडबेस बनना शुरू हो गया है, और आपको बार-बार लेख लाने के लिए कोड लिखना होगा। आप कह सकते हैं "कोड को कॉपी करें और जहां भी आपको सभी लेख लाने की आवश्यकता हो, उसे पेस्ट करें।"

कोई नुकसान नहीं हुआ, किसी की जान नहीं गई। सही?

उस समय एक बड़ा लाल अलार्म आपके दिमाग में चमकना शुरू कर देना चाहिए।

हैलो रिपॉजिटरी।

एक रिपॉजिटरी केवल एक ऑब्जेक्ट है जो आपके मॉडल को एक ही स्थान पर क्वेरी करने के लिए सभी कोड को एनकैप्सुलेट करता है, इसलिए यदि आप चाहते हैं कि आपके पास प्रविष्टि का एक एकल बिंदु है। सभी लेख प्राप्त करें।

चलो एक रिपॉजिटरी ऑब्जेक्ट बनाते हैं जो लेख प्राप्त करने के लिए एक सार्वजनिक एपीआई प्रदान करता है।

अब हम इस विधि को कॉल कर सकते हैं और हमें इस बात की चिंता नहीं करनी चाहिए कि वास्तविक लेख प्राप्त करने के लिए पर्दे के पीछे क्या होता है।
बस विधि को बुलाओ, और आपको लेख मिलते हैं। अच्छा लगा ना?
लेकिन रुकिए, और भी है!

सभी लेख सहभागिता संभालें

हम अपने मॉडल ऑब्जेक्ट के साथ बातचीत करने के लिए अधिक तरीकों को जोड़ने के लिए रिपॉजिटरी का उपयोग कर सकते हैं। ज्यादातर बार आप अपने मॉडल पर CRUD (क्रिएट, रीड, अपडेट, डिलीट) ऑपरेशन करना चाहते हैं। ठीक है, बस रिपॉजिटरी में इन ऑपरेशन के लिए तर्क जोड़ें।

यह आपके कोड में उपयोग करने के लिए एक अच्छा एपीआई बनाता है, एक ही कोड को बार-बार दोहराने के बिना।

व्यवहार में, भंडार का उपयोग इस तरह दिखेगा।

काफी अच्छा और पठनीय, सही? लेकिन, प्रतीक्षा यह और भी बेहतर हो जाती है।

पावर-अप: प्रोटोकॉल

पिछले कोड में, मैंने हमेशा ’एपीआई से डेटा प्राप्त करने’ के उदाहरण का उपयोग किया था। लेकिन क्या होगा अगर आपको ऑनलाइन स्रोत के बजाय स्थानीय JSON फ़ाइल से डेटा लोड करने के लिए समर्थन जोड़ने की आवश्यकता है।

यदि आप एक प्रोटोकॉल बनाते हैं जो विधि के नामों को सूचीबद्ध करता है, तो आप ऑनलाइन एपीआई और एक डेटा ऑफ़लाइन प्राप्त करने के लिए एक कार्यान्वयन बना सकते हैं।

यह इस तरह दिख सकता है।

एक प्रोटोकॉल सिर्फ यह कहता है you यदि आप मेरे अनुरूप हैं, तो आपको इन विधियों के हस्ताक्षर की आवश्यकता है, लेकिन मुझे वास्तविक कार्यान्वयन की परवाह नहीं है! '

तो यह बहुत अच्छा है, आप एक WebArticleRepository और एक LocalArticleRepository बना सकते हैं। उनके पास सभी तरीके हैं जो प्रोटोकॉल में सूचीबद्ध हैं, लेकिन आप 2 पूरी तरह से अलग-अलग कार्यान्वयन लिख सकते हैं।

पावर-अप: यूनिट परीक्षण

जब आप यूनिट को अपने कोड का परीक्षण करना चाहते हैं, तो प्रोटोकॉल का उपयोग वास्तव में सुविधाजनक है, क्योंकि आप केवल एक अन्य ऑब्जेक्ट बना सकते हैं जो रिपॉजिटरी प्रोटोकॉल को लागू करता है, लेकिन इसके बजाय नकली डेटा देता है।

यदि आप निर्भरता इंजेक्शन के साथ मिलकर इसका उपयोग करते हैं, तो यह एक विशिष्ट वस्तु का परीक्षण करना वास्तव में आसान बनाता है।

एक उदाहरण

मान लें कि आपके पास एक दृश्य मॉडल है, और दृश्य मॉडल एक रिपॉजिटरी के माध्यम से अपना डेटा प्राप्त करता है।

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

सौभाग्य से इसे हल करने के लिए वास्तव में सरल है।

हैलो, निर्भरता इंजेक्शन।

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

लेकिन शायद आप सोच रहे हैं कि क्या प्रकार हैं? एक WebArticleRepository MockArticleRepository नहीं है, इसलिए कंपाइलर शिकायत नहीं करेगा? ठीक है, यदि आप प्रोटोकॉल का उपयोग एक प्रकार के रूप में नहीं करते हैं। इस तरह से हम संकलक को जाने देते हैं, जब तक वह ArticleRepository प्रोटोकॉल (जो वेब और MockArticleRepository दोनों करते हैं) के अनुरूप है, तब तक सब कुछ करने की अनुमति देता है।

अंतिम कोड इस तरह दिखेगा।

और अपने यूनिट टेस्ट में आप इसे इस तरह स्वैप कर सकते हैं।

अब आपका पूरा अधिकार है कि आपका रिपॉजिटरी रिटर्न किस डेटा पर है।

सुपर पावर-अप: जेनरिक

आप इसे आगे भी ले सकते हैं, जेनेरिक का उपयोग करके। यदि आप इसके बारे में सोचते हैं, तो अधिकांश रिपॉजिटरी में हमेशा समान संचालन होता है

  1. सभी चीजें प्राप्त करें
  2. कुछ चीजें प्राप्त करें
  3. कुछ चीजें डालें
  4. हटाइए बात
  5. एक बात अपडेट करें

खैर केवल एक चीज जो अलग है वह है, चीज ’शब्द, इसलिए यह जेनेरिक के साथ एक प्रोटोकॉल का उपयोग करने के लिए एक उत्कृष्ट उम्मीदवार हो सकता है। यह जटिल लग सकता है, लेकिन वास्तव में यह करना काफी सरल है।

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

इसलिए अब हम इस प्रोटोकॉल का उपयोग हमारे पास मौजूद किसी भी मॉडल ऑब्जेक्ट के लिए कर सकते हैं।

1. लेख भंडार

संकलक T से अनुच्छेद के प्रकार का अनुमान लगाएगा, क्योंकि विधियों को लागू करने से, हमने निर्दिष्ट किया है कि T क्या है। इस मामले में एक अनुच्छेद वस्तु।

2. उपयोगकर्ता रिपोजिटरी

बस।

मुझे उम्मीद है कि आपको लेख अच्छा लगा होगा और यदि आपका कोई प्रश्न या टिप्पणी है, तो बस उनसे नीचे पूछें या ट्विटर पर मेरे पास पहुंचें और चैट करें।