स्वच्छ वास्तुकला। प्रस्तुतकर्ता की नौकरियां क्या हैं?

Question

मैं clean architecture के बारे में कुछ लेख पढ़ रहा हूं, और इसे एंड्रॉइड में कैसे कार्यान्वित किया जा सकता है। मैंने sample app देखा जो इसके एंड्रॉइड कार्यान्वयन को दिखाता है। इसके अलावा, मैं एक अच्छा talk on Clean architecture on Android

तो, मैं ज्यादातर अवधारणाओं को समझता हूं, लेकिन कुछ स्पष्टता है कि मैं कुछ चीजों को प्राप्त करना चाहता हूं।

मेरी समझ के अनुसार,

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

मैं भंडार की तरह भीतरी परतों के बारे में अधिक जानकारी के लिस्टिंग नहीं कर रहा हूँ के बाद से मेरे सवाल उपर्युक्त चरणों

यहाँ से संबंधित है, प्रस्तोता UseCases के बीच एक मध्यस्थ के रूप में कार्य करने में ही काम करता है और यूआई, एक डेटा प्रेषक के रूप में?

क्या यह केस मॉडल रूपांतरण और इसके विपरीत उपयोग करने के लिए केवल दृश्य मॉडल करता है?

इनपुट सत्यापन तर्क किस परत पर भरोसा करते हैं? क्या यह प्रस्तुति के अंदर हो सकता है? उदाहरण के लिए, अगर हम एक साइन-अप प्रक्रिया के एक छोटे से उपयोग के मामले,

एक बार जब उपयोगकर्ता का निश्चय कर लिया है और साइन अप बटन क्लिक किया है, और डेटा प्रस्तोता के लिए भेजा लेते हैं, यह

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

और दूसरा सवाल यह है कि नेविगेशन को नियंत्रित कौन करता है? व्यू या प्रस्तुतकर्ता या उपयोगकेस?

जो निर्णय लेता है कि आगे कहां जाना है?

उदाहरण के लिए - लॉगिन प्रक्रिया के उपयोग के मामले पर विचार करें, जहां उपयोगकर्ता प्रमाण-पत्र दर्ज करेगा और ठीक क्लिक करेगा।

सफल प्रवेश पर,

• उपयोगकर्ताओं को ईमेल सत्यापित नहीं है, तो सत्यापित करें स्क्रीन ईमेल करने के लिए जाना
• उपयोगकर्ताओं प्रोफ़ाइल पूरा नहीं है, तो प्रोफ़ाइल सेट अप उसके बाद ही होम स्क्रीन
करने के लिए जाना
• तो उपयोगकर्ता नया है,, नए प्रस्तावों स्क्रीन दिखाई और कुछ सीधे होम स्क्रीन

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

प्रश्न को बहुत लंबा बनाने के लिए खेद है, लेकिन मैं बस अपनी वर्तमान समझ को विस्तारित करना चाहता था। अग्रिम

Answer 1

यहाँ धन्यवाद, प्रस्तोता UseCases और यूआई के बीच एक मध्यस्थ के रूप में कार्य कर , एक डेटा डिस्पैचर के रूप में की केवल काम है?

हाँ

इनपुट सत्यापन लॉजिक्स जो परत पर भरोसा करते हैं? क्या यह प्रस्तुतकर्ता के अंदर हो सकता है?

प्रमाणीकरण व्यापार परत पर निर्भर होना चाहिए प्रस्तुति नहीं, क्या यह प्रस्तुतकर्ता के अंदर हो सकता है? यकीन है कि यह हो सकता है, लेकिन क्या होगा यदि आपके पास समान स्क्रीन लेने वाली कई स्क्रीनें हैं, तो क्या आपको प्रत्येक प्रस्तुतकर्ता के अंदर अपना सत्यापन तर्क दोहराना होगा! आप तर्क दे सकते हैं कि आप बेस प्रस्तुतकर्ता बना सकते हैं, लेकिन यह सही समाधान नहीं है, क्योंकि प्रस्तुतकर्ता के पास एक उद्देश्य होना चाहिए।

और दूसरा सवाल यह है कि नेविगेशन को नियंत्रित कौन करता है? व्यू या प्रस्तुतकर्ता या उपयोगकेस?

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

संपादित करें: 0

कैसे आप मॉड्यूल, जहां वे विभिन्न मॉडलों के बीच डेटा पास?

आप बस मैपर का उपयोग करते हैं, और प्रत्येक मॉड्यूल के अपने मॉडल या इकाइयों को बनाने का कारण है, इसलिए प्रत्येक मॉड्यूल को अलग से परीक्षण करना आसान होगा।

प्रस्तुतकर्ता के बारे में और देखें, मान लीजिए कि आप त्रुटि संदेश दिखाना चाहते हैं, प्रस्तुतकर्ता तय करता है कि यह क्यों दिखाया जाएगा, यह तय करें कि यह कैसे दिखाया जाएगा।

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

संपादित करें: 1
अंतिम बिंदु को जोड़ने, यह स्पष्ट है कि गूगल अब और सहायता टीम वहाँ एक महान पुस्तकालयों की "Architecture components" महान सेट शुरू के माध्यम से गतिविधियां और टुकड़े संभव के रूप में डमी विचारों बनाने के लिए प्रयास किया जाता है । मैं किसी को भी उन्हें जांचने के लिए प्रोत्साहित करता हूं, भले ही आप एमवीपी का उपयोग कर रहे हों, आपको एक बड़ा लाभ मिलेगा।