RxVMS - स्पंदन अनुप्रयोगों के लिए एक व्यावहारिक वास्तुकला

फ़्लटर के एप्लिकेशन आर्किटेक्चर के बारे में मेरी समझ के बारे में प्रकाशनों की एक श्रृंखला में यह पहली पोस्ट है। मैं आपको चेतावनी देता हूं - यह बहुत आत्म-विश्वास होगा ।

अब तक की योजना बनाई:

• परिचय (यह पोस्ट)
• डार्ट स्ट्रीम बेसिक्स
• RxDart: प्रवाह के जादुई रूपांतरण
• RxVMS मूल बातें: RxCommand और GetIt
• RxVMS: सेवाएं और प्रबंधक
• RxVMS: स्व-निहित विजेट
• RxVMS के साथ उपयोगकर्ता प्रमाणीकरण

प्रस्तावना

मैं लगभग 20 वर्षों से प्रोग्रामिंग में हूँ। मैंने 4 साल पहले Xamarin.Forms के साथ मोबाइल विकास शुरू किया, क्योंकि इंडी डेवलपर के रूप में क्रॉस-प्लेटफॉर्म मेरे लिए एकमात्र प्रेरणा था। Xamarin.Forms शाब्दिक रूप से आपको MVVM पैटर्न का उपयोग करने के लिए प्रेरित कर रहा है, क्योंकि UI को XAML में परिभाषित किया गया है, और आपको मॉडल के साथ UI को गोंद करने के लिए किसी प्रकार की परत की आवश्यकता है। ज़ामरीन के साथ काम करने की प्रक्रिया में, मैं रिएक्टिवुइ से मिला और शाब्दिक रूप से उन धाराओं और प्रतिक्रियात्मक एक्सटेंशन ( आरएक्स ) से मोहित हो गया, जिन्होंने मेरे अनुप्रयोगों को और अधिक विश्वसनीय बना दिया।

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

• InheritedWidget : मैं विजेट ट्री के केवल परिवर्तित भाग को अपडेट नहीं कर सकता, इसलिए मैंने इसका उपयोग केवल डार्ट स्ट्रीम (डार्ट स्ट्रीम) को प्रकाशित करने वाले मॉडल वर्गों तक पहुंचने के लिए किया, लेकिन जल्द ही इस विचार को टेम्प्लेट सर्विस लोकेटर के पक्ष में छोड़ दिया
• स्कोप्ड मॉडल InheritedWidget तुलना में अधिक दिलचस्प है, लेकिन इसने मुझे उतना लचीलापन नहीं दिया, जितना मुझे रिएक्टिवयूआई के साथ इस्तेमाल किया गया था
• Redux रिएक्ट नेटिव से परिचित कई डेवलपर्स द्वारा सुझाया गया टेम्प्लेट था। मेरे पास पूरी पोस्ट है कि मुझे यह क्यों पसंद नहीं है।
• बीएलओसी : अगर मैंने पहले से ही एक ऐसे समय में अपना खुद का पैटर्न विकसित करना शुरू नहीं किया था, जब बीएलओसी आगे बढ़ना शुरू हुआ था, तो सबसे अधिक संभावना है कि मैंने इसे लिया होगा, क्योंकि यह वास्तव में लचीला और प्रतिक्रियाशील है। मुझे यह पसंद नहीं है कि यह स्ट्रीम सिंक प्रकाशित करता है और मैं विजेट के ईवेंट हैंडलर में केवल फ़ंक्शन या कमांड नहीं ले सकता हूं। इसके अलावा, बीएलओसी आपको यह नहीं बताता है कि आपके आवेदन को समग्र रूप से कैसे बनाया जाए और न ही यह स्पष्ट परिभाषा है कि एक निश्चित बीएलओसी कितना बड़ा होना चाहिए या इसका दायरा क्या है
• MVVM : जब से मैंने उसके साथ काम किया है, यह पहली ऐसी चीज है जिसके बारे में मुझे उम्मीद थी कि मैं Flutter में लागू करूंगा। लेकिन नहीं! ViewModel की बात यह है कि बाइंडिंग के माध्यम से व्यू में अपने मॉडल का प्रतिनिधित्व प्रदान करें। लेकिन फ़्लटर अपने मॉडल को नए डेटा के साथ अपडेट नहीं करता है, यह हमेशा उन्हें फिर से बनाता है, जैसा कि मैंने पहले ही वर्णित किया है । इसके अलावा, ViewModels को हमेशा बेस मॉडल के साथ सिंक्रनाइज़ किया जाना चाहिए, जो अप्रिय बग की ओर जाता है, और वास्तविकता से पता चलता है कि अनुप्रयोगों में ViewModels का पुन: उपयोग करने का वादा किया गया लाभ लगभग कभी प्राप्त नहीं हुआ है। एडम पेडले के पास इन खामियों के बारे में एक शानदार पोस्ट है

परत अतिरेक के बारे में कठोर सच्चाई

यह इस विचार के लिए लगभग एक हठधर्मिता है कि विकास में आपको हमेशा कई परतों में अपने आवेदन का निर्माण करना चाहिए, जिनमें से प्रत्येक में केवल अंतर्निहित तक पहुंच है, क्योंकि यह आपको अनुमति देगा:

• अन्य परियोजनाओं में परतों का पुन: उपयोग करें
• पारदर्शी रूप से एक परत को दूसरे के साथ बदलें
• परीक्षण को सरल बनाएं

हालांकि:

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

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

स्पंदन के लिए आदर्श वास्तुकला

तो एक आदर्श वास्तुकला से मुझे क्या उम्मीद है?

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

विजेट स्वतंत्रता

स्टेटलेस इंटरफ़ेस तत्वों की प्रकृति के आधार पर, फ़्लटर में कोई पृष्ठ / विजेट दूसरों पर निर्भर या प्रभावित नहीं होना चाहिए। यह इस विचार की ओर जाता है कि प्रत्येक पृष्ठ / विजेट स्वतंत्र रूप से उपयोगकर्ता के साथ स्वयं और उसके सभी इंटरैक्शन को प्रदर्शित करने के लिए जिम्मेदार होना चाहिए।

RxVMS

RxVMS पिछले अनुप्रयोग में वर्णित RxVAMS पैटर्न का एक विकास है, जिसके व्यावहारिक अनुप्रयोग के दौरान कुछ समस्याओं की पहचान की गई थी और उन्हें ठीक किया गया था।

इन सभी विचारों का वर्तमान परिणाम RxVMS, या Rx-View-Managers-Services पैटर्न है। यह उपरोक्त सभी कार्यों को एकमात्र आवश्यकता के साथ करता है जिसे आपको आरएक्स थ्रेड्स और तत्वों को समझना चाहिए। इसमें आपकी मदद करने के लिए, मैं निम्नलिखित पोस्ट समर्पित करता हूं।

यहाँ मेरे आवेदन की एक संक्षिप्त रूपरेखा है

सेवा (सेवा)

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

प्रबंधक (प्रबंधक)

प्रबंधक समूह समान रूप से समान कार्यक्षमता, जैसे प्रमाणीकरण, आदेश देने की प्रक्रिया और पसंद करते हैं। प्रबंधक किसी वस्तु की स्थिति में हेरफेर करते हैं।

राज्य में कोई भी परिवर्तन (एप्लिकेशन डेटा में परिवर्तन) केवल प्रबंधकों के माध्यम से किया जाना चाहिए। एक नियम के रूप में, प्रबंधक स्वयं डेटा स्टोर नहीं करते हैं, सिवाय प्रदर्शन या रनटाइम स्थिरांक के मामलों में।

प्रबंधक प्रॉक्सी डेटा स्रोतों के रूप में काम कर सकते हैं, यदि सेवाओं से अनुरोध के बाद उनके कुछ परिवर्तन की आवश्यकता होती है। एक उदाहरण एक दृश्य में प्रदर्शन के लिए दो या अधिक स्रोतों से डेटा का संयोजन कर रहा है।

प्रबंधक आपस में बातचीत कर सकते हैं।

दृश्य (प्रदर्शन, vyuha)

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

डोमेन ऑब्जेक्ट

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

निम्नलिखित पोस्ट इन तत्वों के सार और बातचीत को प्रकट करेंगे।