बड़ी परियोजनाओं में वास्तुकला के मुद्दे

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

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

एक मोबाइल एप्लिकेशन के विकास की शुरुआत में, नेता या डिजाइनर इस सवाल का सामना करते हैं - किस वास्तुशिल्प पैटर्न का उपयोग करना है? हमारे स्टूडियो में एक सामान्य वास्तुशिल्प पैटर्न MVP है। शुद्ध एमवीपी अपने शुद्ध रूप में निश्चित रूप से अच्छा है (नीचे दी गई छवि देखें), लेकिन हम इस पैटर्न को अंतिम रूप नहीं देते, तो हम वास्तविक डेवलपर नहीं होंगे। वे एक विकल्प पर नहीं रुके, और हमें शुद्ध एमवीपी से दो शाखाएँ मिलीं।

इसलिए, डिजाइन चरण में, हमें एक को चुनने के कार्य के साथ सामना करना पड़ा, और आमतौर पर स्वीकृत और समझने योग्य वास्तुशिल्प पैटर्न के आधार पर आगे बढ़ते हैं। लेकिन, पहले से ही इस तरह के शुरुआती चरण में, हम एक गलती करने में कामयाब रहे, जिसने बाद में हमें कई समस्याएं दीं।

आइए स्टेरॉयड पर हमारे दो एमवीपी देखें।

SurfMVP

छवि से पता चलता है कि, सामान्य एमवीपी की तुलना में, बहुत कुछ नहीं बदला है। IOS एप्लिकेशन में स्क्रीन के बीच स्विच करने पर हमने कुछ समस्याएं देखीं। संक्रमण से पहले नई स्क्रीन बनाने के लिए तर्क की एक बड़ी मात्रा सीधे UIViewController में केंद्रित है, यह हमें काफी सही नहीं लग रहा था, इसलिए पहली बात हमने एक अलग राउटर इकाई को उजागर किया था, जो कि एप्लिकेशन में स्क्रीन के बीच संक्रमण बनाने के लिए जिम्मेदार है।
SurfMVP में मॉडल वे सेवाएं हैं जो प्रस्तुतकर्ता डेटा को पुनः प्राप्त करने के लिए आमंत्रित करता है। अक्सर, एक सेवा पूरे मॉड्यूल के लिए कार्यों को हल करती है, लेकिन कठिन परिस्थितियों में आपको कई के साथ बातचीत करनी होती है।
विन्यासकर्ता इकाई एक अलग मॉड्यूल के निर्माण के लिए जिम्मेदार है, यह सभी आवश्यक घटकों को इनिशियलाइज़ करता है और उनके बीच निर्भरता पैदा करने के लिए जिम्मेदार है।

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

आइए उन पर अलग से विचार करें:

ViewInput - कार्यान्वयन स्वयं देखें , प्रस्तुतकर्ता लिंक रखता है। यह प्रोटोकॉल उन तरीकों का वर्णन करता है जिनके द्वारा प्रस्तुतकर्ता दृश्य को नियंत्रित कर सकता है, डेटा स्थानांतरित कर सकता है, स्थिति बदल सकता है, और इसी तरह।

ViewOutput - प्रस्तुतकर्ता को लागू करता है, दृश्य इसके लिए एक लिंक रखता है। प्रोटोकॉल दृश्य में हो सकने वाली क्रियाओं का एक सेट और जीवन चक्र विधियों का वर्णन करता है, उदाहरण के लिए, स्क्रीन के साथ उपयोगकर्ता इंटरैक्शन की घटनाएं।

राउटरइन्पुट - राउटर को लागू करता है, और प्रस्तुतकर्ता इसके लिए एक लिंक रखता है, क्योंकि यह एप्लिकेशन में आगे नेविगेशन शुरू करने के लिए एकमात्र जिम्मेदार है।

ModuleTransitionable - दृश्य कार्यान्वित किया जाता है, राउटर इसके लिए एक लिंक रखता है। यह SurfMVP में एकमात्र "मूल" प्रोटोकॉल है। एप्लिकेशन नेविगेशन के साथ काम करने के तरीकों के एक सेट के साथ राउटर प्रदान करने के लिए इसकी आवश्यकता है।

मॉड्यूलइन्पुट - इम्प्लीमेंट्स प्रस्तुतकर्ता । इस प्रोटोकॉल में वे विधियां होनी चाहिए जिनके द्वारा इस प्रोटोकॉल के लिए लिंक रखने वाला एक अन्य मॉड्यूल वर्तमान मॉड्यूल की स्थिति को बदल सकता है।

ModuleOutput - कॉलिंग मॉड्यूल के प्रस्तुतकर्ता को लागू करता है, लिंक को कॉल किए गए मॉड्यूल का प्रस्तुतकर्ता रखता है। यदि प्रोफ़ाइल स्क्रीन को समाचार मॉड्यूल से प्रदर्शित किया जा सकता है, तो NewsPresenter को ProfileModuleOutput को लागू करना चाहिए, और ProfilePresenter को इसमें एक लिंक होना चाहिए ।
ModuleOutput को मॉड्यूल के विन्यासकर्ता को पास किया जाता है और वहां प्रस्तुतकर्ता में स्थापित किया जाता है। इसमें मॉड्यूल तरीके शामिल हैं जो कॉलिंग मॉड्यूल के व्यवहार को प्रभावित करते हैं।

SurfMVP समस्या

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

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

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

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

समन्वित SurfMVP

समन्वित SurfMVP एक वास्तुशिल्प पैटर्न है जिसमें, SurfMVP के विपरीत, हमने प्रत्येक व्यक्तिगत मॉड्यूल के अंदर राउटर इकाई को हटा दिया। एक आवेदन के निर्माण का प्रतिमान थोड़ा बदल गया है। मॉड्यूल अब पूरी तरह से स्वतंत्र नहीं हैं। प्रत्येक मॉड्यूल, पूरी तरह से पुन: प्रयोज्य लोगों के अपवाद के साथ, एक अलग से अलग UserFlow में स्थित है, जिसे नियोजित किया जाना चाहिए, उपयोगकर्ता को वांछित परिणाम के लिए अग्रणी कुछ सामान्य क्रिया करनी चाहिए।

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

समन्वित SurfMVP में, राउटर इकाई ने समन्वयक इकाई को प्रतिस्थापित किया, जो अब न केवल एक अलग मॉड्यूल को नेविगेट करने के लिए जिम्मेदार है, लेकिन मॉड्यूल का एक सेट जो तार्किक रूप से एक दूसरे से जुड़े हुए हैं। यह नेविगेशन को आसान बनाता है और एप्लिकेशन के साथ काम करता है। योजनाबद्ध रूप से, हमारा आवेदन इस तरह दिखता है:

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

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

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

समन्वित SurfMVP के पेशेवरों और विपक्ष

फायदे:

1. समन्वयक दृष्टिकोण का मुख्य लाभ आवेदन के भीतर पूरे नेविगेशन ब्लॉकों का पुन: उपयोग करने की क्षमता है। अब, आवेदन में कहीं से भी, इस समन्वयक को कॉल करना संभव है और अपने काम को पूरा करने के अलावा किसी अन्य चीज के बारे में नहीं सोचना चाहिए।
2. चूंकि नेविगेशन तर्क को एक अलग समन्वयक के अंदर अलग किया जाता है, इसलिए अब नेविगेशन का पालन करना बहुत अधिक सुविधाजनक है: बस एक फ़ाइल और पूरी तस्वीर को अपनी आंखों के सामने खोलें। सभी व्यक्तिगत मॉड्यूल को छेदने की आवश्यकता नहीं है ताकि वे यह समझ सकें कि वे किस लिए पहुंच रहे हैं, आवेदन को इकट्ठा करें और डिजाइन को देखें।
3. बड़ी टीमों में डिजाइन करना अधिक सुविधाजनक है। यह पूरे नेविगेशन को बनाने और सभी मॉड्यूल को इनिशियलाइज़ करने के लिए समय आवंटित करने के लिए एक अलग नई सुविधा के डिजाइन चरण में पर्याप्त है, जिसके बाद यह बड़ी संख्या में डेवलपर्स को विकास को सौंप देगा, और एक दूसरे के साथ इन स्क्रीन के एकीकरण के साथ बहुत कम समस्याएं होंगी।
4. Deeplinks और Push-Notifications का एकीकरण अब सिरदर्द नहीं है।

नुकसान:

किसी भी वास्तुशिल्प दृष्टिकोण के साथ, समन्वित SurfMVP के लिए डाउनसाइड हैं।

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

  func runAuthFlow() { let coordinator = AuthCoordinator(router: MainRouter()) coordinator.finishFlow = { [weak self, weak coordinator] in self?.removeDependency(coordinator) } self.addDependency(coordinator) coordinator.start() } 

निष्कर्ष

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

समन्वित SurfMVP का उपयोग कब करें

वास्तव में, जब आप चाहें, तब इसका उपयोग करें, लेकिन हम निम्नलिखित शर्तों का पालन करते हैं:

• स्क्रीन की संरचना जटिल है और परिवर्तन के अधीन है;
• नेविगेशन के साथ डीपलिंक और / या पुश-सूचनाएं हैं;
• एक बड़ी टीम में काम करना आवश्यक है;

SurfMVP का उपयोग कब करें

हम अपने पहले वास्तुशिल्प पैटर्न के बारे में नहीं भूले। हम अभी भी स्टूडियो में इसका उपयोग परियोजनाओं को विकसित करते समय करते हैं यदि यह निम्न स्थितियों को पूरा करता है:

• परियोजना काफी छोटी है और तेजी से विकसित करने की योजना नहीं है;
• परियोजना में एक बहुत ही सरल स्क्रीन संरचना है, और यह मजबूत परिवर्तनों के अधीन नहीं है।

अतिरिक्त सामग्री

• IOS में आर्किटेक्चर
  
• शुद्ध एमवीपी क्या है?
• फ्लैट नेविगेशन क्या है?
• समन्वयकों के बारे में सोरूस खान्लू द्वारा लेख और एक कहानी (जिसके साथ "समन्वयक" शब्द का उपयोग किया गया था)।
  
  1. समन्वयक
  2. समन्वयक Redux
  3. कोकोआहेड स्टॉकहोम \ समन्वयक - सोरूस खान्लौ
• एंड्री पैनोव द्वारा लेख और कार्यान्वयन उदाहरण
  
  1. AndreyPanov / ApplicationCoordinator: समन्वयक आवश्यक ट्यूटोरियल
  2. लेख "समन्वयक आवश्यक ट्यूटोरियल। भाग I »
  3. लेख "समन्वयक आवश्यक ट्यूटोरियल। भाग II »
• आवेदन नेविगेशन पर अपने विचारों के साथ बोगडान ओर्लोव का एक लेख
• समन्वयक के व्यावहारिक उपयोग पर एंड्री रिच्कोव की रिपोर्ट की सामग्री
  
  1. एंड्री रिच्कोव: नेविगेशन से कैसे निपटें
  2. मूनको / कोऑर्डिनेटर। नमूना: एप्लिकेशन समन्वयक उदाहरण

इस लेख में, मैंने आर्किटेक्चर के साथ एक समस्या साझा की, जो हमें काम करते समय सामना करना पड़ा। बेशक, किस वास्तुकला का उपयोग करने का विकल्प आपके साथ रहता है। अगले लेख में मैं बड़ी परियोजनाओं में बैकएंड की समस्याओं को साझा करूंगा और बताऊंगा कि हमने उन्हें कैसे हल किया। देखते रहो!