सामान्य Android आर्किटेक्चर (MVC बनाम MVV बनाम MVVM)

इससे पहले कि हम आर्किटेक्चर पर आगे बढ़ें, आइए इस शब्द को स्पष्ट करें।
गॉड क्लास / ऑब्जेक्ट: क्लास जिसमें घटकों की एक उच्च संख्या होती है, और घटक युग्मित होते हैं। यह एक बहुत बुरा विचार है और उन्हें हर कीमत पर बचना चाहिए। यह एक वास्तुशिल्प पैटर्न है।

एमवीसी: मॉडल व्यू कंट्रोलर

आदर्श:
1. डेटा मॉडल का प्रतिनिधित्व करता है।
2. डेटा स्टेट्स को मैनेज करता है
3. व्यापार तर्क है

राय:
1. जिस तरह से हम अपने डेटा का प्रतिनिधित्व करते हैं उदा। Android में दृश्य / लेआउट।
2. UI को रेंडर करें।

नियंत्रक:
1. हमारे आवेदन के साथ उपयोगकर्ता बातचीत संभालती है।
2. मॉडल और दृश्य के बीच संचार चैनल।
जैसे Android में टुकड़े / गतिविधियाँ।

MVC प्रवाह आरेख की तरह दिखेगा:

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

दृश्य उपयोगकर्ता इनपुट प्राप्त करता है और नियंत्रक को उपयोगकर्ता इनपुट को संभालने के लिए कहता है।
नियंत्रक को दृश्य से इनपुट मिलता है, इस आधार पर कि उपयोगकर्ता ने संदेश को छिपाने / देखने के लिए चुना था। कंट्रोलर मॉडल को डेटा स्टेट (यहां संदेश) अपडेट करने के लिए कहता है।
मॉडल नियंत्रक से इनपुट के आधार पर मॉडल को अपडेट करता है। इस प्रकार इसमें यह व्यावसायिक तर्क है।
नियंत्रकों को अद्यतन डेटा मिलता है और तदनुसार यूआई को अपडेट करता है।

एमवीपी: मॉडल व्यू प्रस्तुतकर्ता

आदर्श:
MVC पैटर्न में भी।

राय:
1. जिस तरह से हम अपने डेटा का प्रतिनिधित्व करते हैं उदा। एंड्रॉइड में व्यूज / लेआउट के साथ-साथ एक्टिविटीज / फ्रैगमेंट्स।
2. प्रस्तुतकर्ता के कार्यों के लिए एक इंटरफ़ेस लागू करेगा।

प्रस्तुतकर्ता:
1. विचारों (MVC के विपरीत) से कोई संबंध नहीं है।
2. संचालन हमारे विचारों द्वारा आह्वान किया जाता है।
3. दृश्य व्यू के इंटरफ़ेस के माध्यम से अपडेट किए जाते हैं।

MVP फ्लो आरेख इस तरह दिखेगा:

हालांकि फ्लो आरेख MVC के समान दिखता है, अंतर यह है कि VIew और Presenters / Controllers एक दूसरे के साथ कैसे बातचीत करते हैं।

एमवीपी में दृश्य और प्रस्तुतकर्ता एक इंटरफेस (एमवीसी के विपरीत) के माध्यम से बातचीत करते हैं। प्रस्तुतकर्ता इंटरफ़ेस पर कुछ कार्रवाई करते हैं, जो दृश्य में कार्यान्वित की जाती है और इसलिए दृश्य अपडेट हो जाता है।

तो मॉडल वही रहता है (जैसा कि MVC में है)।
यहाँ प्रस्तुतकर्ता सिर्फ इंटरफ़ेस क्रिया करता है और इसे अपडेट करने की कोशिश कर रहे दृश्यों का कोई ज्ञान नहीं है।
तो उस इंटरफ़ेस को लागू करने वाले विचार यूआई को अपडेट करते हैं।

यह MVC से कहीं बेहतर है क्योंकि यहाँ प्रस्तुतकर्ता के पास NO ANDROID API है और इसे आसानी से जांचा जा सकता है।
विचारों को अपडेट किया गया है या नहीं यह देखने के लिए एस्प्रेसो आदि का उपयोग करके परीक्षण किया जा सकता है।

इस प्रकार विचार बहुत गूंगे हैं। वे प्रस्तुतकर्ता से डेटा प्राप्त करते हैं और तदनुसार यूआई घटकों को अपडेट करते हैं।

MVVM- मॉडल व्यू व्यूमॉडल

यह व्यू बाइंडिंग कोड को और कम करता है यानी कि मॉडल डेटा के लिए किस तरह से बाइंड है।

एंड्रॉइड इकोसिस्टम में बात करते हुए, यह Google से डेटा बाइंडिंग लाइब्रेरी का उपयोग करता है, और एक्सएम लेआउट में व्यू का बाध्यकारी तर्क लागू होता है।

आदर्श:
MVC / MVP पैटर्न में समान।

राय:
1. MVC / MVP पैटर्न के समान।

ViewModel:
1. इसमें मॉडल होता है।
2. अद्यतन मूल्यों के लिए अवलोकन मूल्यों का उपयोग करता है।
3. मूल्य अद्यतन पर, प्रासंगिक विचारों को अपडेट मिलेगा (डेटा बाइंडिंग लाइब्रेरी का उपयोग करता है)।

MVP फ्लो आरेख इस तरह दिखेगा:

तो दृश्य उपयोगकर्ता इंटरैक्शन प्राप्त करता है और दृश्य मॉडल को सूचित करेगा।
अब ViewModel मॉडल के साथ-साथ ऑब्जर्वेबल (जो मूल्य परिवर्तन को लागू करेगा) को अपडेट करेगा। अगला, ViewModel इंटरफ़ेस UI (XML लेआउट) को सीधे अपडेट करेगा।

तो देखने के लिए अर्थात् XML फ़ाइल की तरह दिखेगा:

इसलिए जैसा कि टेक्स्टव्यू दिखाया गया है कि संदेश के परिवर्तन के रूप में यहां सीधे अपने पाठ को अपडेट किया जा सकता है।

एमवीसी / एमवीपी / एमवीवीएम के बीच तुलना:

MVP और MVVM के विपरीत, नियंत्रकों (Android में गतिविधियाँ) Android पर एक उच्च निर्भरता है, और इसलिए यह MVP / MVVM में इकाई परीक्षण के लिए आसान है।

हालांकि, XML- डेटा-बाइंडिंग उद्देश्यों के लिए MVVM में अधिक जटिल है।