उपयुक्त iOS आर्किटेक्चर कैसे चुनें (भाग 2)

एमवीसी, एमवीपी, एमवीवीएम, वीआईपी, या वीआईपी

आप यहां भाग एक से परामर्श कर सकते हैं।

मुख्य iOS आर्किटेक्चर

संक्षिप्त विवरण।

MVC

MVC परतें इस प्रकार हैं:

एम: बिजनेस लॉजिक, नेटवर्क लेयर और डेटा एक्सेस लेयर

V: UI लेयर (UIKit चीजें, स्टोरीबोर्ड, Xibs)

C: मॉडल और दृश्य के बीच मध्यस्थता का समन्वय करता है।

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

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

एमवीसी चक्र का एक उदाहरण:

  1. दृश्य परत में एक उपयोगकर्ता कार्रवाई / घटना (उदाहरण: ताज़ा कार्रवाई) निकाल दिया जाता है और उस कार्रवाई को नियंत्रक को सूचित किया जाता है
  2. कंट्रोलर जो मॉडल लेयर से डाटा मांगता है
  3. नियंत्रक को रिटर्न डेटा मॉडल
  4. कंट्रोलर कहता है कि व्यू के लिए अपने स्टेट को नए डेटा के साथ अपडेट करें
  5. उनके राज्य को अद्यतन देखें

Apple MVC

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

व्यूकंट्रोलर में व्यू होता है और मॉडल का मालिक होता है। समस्या यह है कि हम नियंत्रक कोड के साथ-साथ ViewController में दृश्य कोड लिखने के लिए उपयोग किया जाता है।

MVC अक्सर बड़े पैमाने पर देखने वाले नियंत्रक समस्या को बनाता है, लेकिन यह केवल होता है और पर्याप्त जटिलता वाले ऐप्स में एक गंभीर बात बन जाती है।

कुछ तरीके हैं जो डेवलपर व्यू कंट्रोलर को अधिक प्रबंधनीय बनाने के लिए उपयोग कर सकते हैं। कुछ उदाहरण:

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

एमवीसी बनाम एमवीपी

आप देख सकते हैं कि एमवीपी का आरेख एमवीसी के समान है

एमवीसी एक कदम आगे था, लेकिन यह अभी भी कुछ चीजों के बारे में अनुपस्थिति या चुप्पी द्वारा चिह्नित किया गया था।

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

एमवीसी में मुझे लगता है कि यह दर्शाने के लिए कुछ भी नहीं है कि नियंत्रक को दृश्य (अनुपस्थिति) के विशिष्ट कार्यान्वयन का पता नहीं होना चाहिए।

HTML व्यू लेयर का हिस्सा था और कई मामले बकवास के रूप में गूंगे थे। कुछ मामलों में, यह केवल उपयोगकर्ता से ईवेंट प्राप्त करता है और GUI की दृश्य सामग्री प्रदर्शित करता है।

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

प्रेजेंटेशन लॉजिक वह तर्क है जो यह दर्शाता है कि UI को कैसे प्रदर्शित किया जाना चाहिए और UI तत्वों को आपस में कैसे जोड़ा जाता है। एक उदाहरण नियंत्रण तर्क है जब एक लोडिंग संकेतक को / चेतन दिखाना शुरू करना चाहिए और कब इसे दिखाना / बंद करना चाहिए।

MVP और MVVM में व्यू लेयर को बिना किसी तर्क या बुद्धिमत्ता के बकवास के रूप में गूंगा होना चाहिए और iOS में व्यू कंट्रोलर व्यू लेयर का हिस्सा होना चाहिए। दृश्य के गूंगे होने का अर्थ है कि प्रस्तुति तर्क दृश्य परत से बाहर भी है।

एमवीसी की समस्याओं में से एक यह है कि यह स्पष्ट नहीं है कि प्रस्तुति तर्क कहाँ रहना चाहिए। वह बस इस बारे में चुप है। क्या प्रेजेंटेशन लॉजिक व्यू लेयर में या मॉडल लेयर में होना चाहिए?

यदि मॉडल की भूमिका केवल "कच्चे" डेटा प्रदान करने की है, तो इसका मतलब है कि दृश्य में कोड होगा:

निम्नलिखित उदाहरण पर विचार करें: हमारे पास एक उपयोगकर्ता है, पहला नाम और अंतिम नाम। दृश्य में, हमें उपयोगकर्ता नाम "लास्टनाम, फर्स्टनाम" (जैसे "फ़्लोरेस, टियागो") प्रदर्शित करने की आवश्यकता है।

यदि मॉडल की भूमिका "कच्चा" डेटा प्रदान करने की है, तो इसका मतलब है कि दृश्य में कोड होगा:

पहले नाम दें = userModel.getFirstName ()
अंतिम नाम दें = userModel.getLastName ()
nameLabel.text = lastName + ”,“ + पहला नाम

तो इसका मतलब है कि यह यूआई लॉजिक को संभालने की व्यू की जिम्मेदारी होगी। लेकिन यह यूआई लॉजिक को यूनिट टेस्ट के लिए असंभव बनाता है।

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

नाम दें = userModel.getDisplayName ()
nameLabel.text = नाम

एमवीपी उस बारे में स्पष्ट है और प्रस्तुति तर्क प्रस्तुतकर्ता परत में रहता है। इससे प्रस्तुतकर्ता परत की परीक्षण क्षमता बढ़ जाती है। अब मॉडल और प्रस्तुतकर्ता परत आसानी से परीक्षण योग्य है।

आम तौर पर एमवीपी कार्यान्वयन में, व्यू एक इंटरफ़ेस / प्रोटोकॉल के पीछे छिपा होता है और इसमें प्रस्तुतकर्ता में UIKit का कोई संदर्भ नहीं होना चाहिए।

ध्यान रखने योग्य एक और बात यह है कि सकर्मक निर्भरताएँ।

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

अलग-अलग परतें अलग-अलग कारणों से और अलग-अलग दरों पर भी बदलती हैं। इसलिए जब आप एक परत बदलते हैं तो आप यह नहीं चाहते हैं कि दूसरी परतों में द्वितीयक प्रभाव / समस्या पैदा हो।

प्रोटोकॉल कक्षाओं की तुलना में अधिक स्थिर होते हैं। प्रोटोकॉल कार्यान्वयन विवरणों और अनुबंधों के साथ नहीं होते हैं, इसलिए एक परत के कार्यान्वयन विवरण को अन्य परतों को प्रभावित किए बिना बदलना संभव है।

इसलिए अनुबंध (प्रोटोकॉल) परतों के बीच एक डिकूपिंग बनाते हैं।

MVP बनाम MVVM

MVVM आरेख

एमवीपी और एमवीवीएम के बीच मुख्य अंतर यह है कि एमवीपी में प्रस्तुतकर्ता इंटरफेस के माध्यम से व्यू के साथ संचार करता है, और एमवीवीएम में व्यू डेटा और घटनाओं में परिवर्तन के लिए उन्मुख है।

एमवीपी में हम इंटरफेस / प्रोटोकॉल का उपयोग करके प्रस्तुतकर्ता और दृश्य के बीच मैनुअल बाइंडिंग करते हैं।
MVVM में हम RxSwift, KVO जैसी किसी चीज़ का उपयोग करके स्वचालित डेटा बाइंडिंग बनाते हैं या जेनरिक और क्लोजर के साथ एक तंत्र का उपयोग करते हैं।

MVVM में हमें ViewModel और View के बीच एक अनुबंध (जैसे: जावा इंटरफ़ेस / iOS प्रोटोकॉल) की भी आवश्यकता नहीं है क्योंकि हम आमतौर पर ऑब्जर्वर डिज़ाइन पैटर्न के माध्यम से संवाद करते हैं।

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

लोडिंग इंडिकेटर के प्रेजेंटेशन लॉजिक के बारे में सोचें। MVP में प्रस्तुतकर्ता ViewProtocol.showLoadingIndicator करता है। MVVM में ViewModel में एक isLading संपत्ति हो सकती है। स्वचालित डेटा बाइंडिंग के माध्यम से दृश्य परत का पता चलता है जब यह गुण बदलता है और स्वयं को ताज़ा करता है। MVP MVVM की तुलना में अधिक आवश्यक है क्योंकि प्रस्तुतकर्ता आदेश देता है।

एमवीवीएम सीधे आदेशों की तुलना में डेटा परिवर्तनों के बारे में अधिक है, और हम डेटा परिवर्तनों और अपडेट को देखने के बीच संबंध बनाते हैं। यदि MVVM के साथ मिलकर RxSwift और कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग प्रतिमान का उपयोग करते हैं, तो हमने कोड को और भी कम आवश्यक और अधिक घोषित कर दिया है।

MVVM MVP की तुलना में परीक्षण करना अधिक आसान है क्योंकि MVVM ऑब्जर्वर डिज़ाइन पैटर्न का उपयोग करता है जो कि घटक के बीच डेटा को डिकोड किए गए तरीके से स्थानांतरित करता है।
इसलिए हम केवल दृश्य और प्रस्तुतकर्ता के बीच संचार का परीक्षण करने के लिए तरीकों को कॉल करने के बजाय दो वस्तुओं की तुलना करके डेटा में परिवर्तन को देखकर परीक्षण कर सकते हैं।

पुनश्च: मैंने लेख को कुछ अपडेट किया जिससे यह बहुत बढ़ गया, इसलिए इसे तीन भागों में विभाजित करना आवश्यक था। आप यहाँ तीन भाग पढ़ सकते हैं।

भाग दो यहाँ समाप्त होता है। सभी प्रतिक्रिया स्वागत योग्य है। भाग तीन में VIPER, VIP, रिएक्टिव प्रोग्रामिंग, ट्रेड-ऑफ्स, बाधाओं और प्रासंगिक सेंस के बारे में बात की जाएगी।

पढ़ने के लिए धन्यवाद! अगर आपको यह लेख पसंद आया है, तो कृपया ताली बजाएं
तो अन्य लोग भी इसे पढ़ सकते हैं :)