स्वच्छ वास्तुकला: मॉडल क्या है?

Question

अपनी पुस्तक 'क्लीन आर्किटेक्चर' में, अंकल बॉब का कहना है कि प्रस्तुतकर्ता को वह डेटा प्राप्त करना चाहिए जिसे वह प्राप्त करता है जिसे वह 'आदर्श मॉडल' कहता है।

क्या यह मॉडल-व्यू-व्यूमॉडल (एमवीवीएम) डिज़ाइन पैटर्न से 'व्यूमॉडल' के समान है या यह एक साधारण डेटा ट्रांसफर ऑब्जेक्ट (डीटीओ) है?

यदि यह एक साधारण डीटीओ नहीं है, तो यह व्यू से कैसे संबंधित है? क्या पर्यवेक्षक संबंध के माध्यम से इसे देखने से अपडेट मिलता है?

मेरा अनुमान है कि यह MVVM के व्यूमॉडल की तरह अधिक है, क्योंकि उनकी पुस्तक के अध्याय 23 में रॉबर्ट मार्टिन कहते हैं:

[प्रस्तुतकर्ता का] काम आवेदन से डेटा स्वीकार करना और इसे प्रस्तुति के लिए प्रारूपित करना है ताकि दृश्य बस इसे स्क्रीन पर स्थानांतरित कर सके। उदाहरण के लिए, यदि एप्लिकेशन किसी फ़ील्ड में प्रदर्शित दिनांक चाहता है, तो वह प्रस्तुतकर्ता को दिनांक ऑब्जेक्ट सौंप देगा। प्रस्तुतकर्ता फिर उस डेटा को एक उपयुक्त स्ट्रिंग में प्रारूपित करेगा और इसे एक सरल डेटा संरचना में रखेगा जिसे व्यू मॉडल कहा जाता है, जहां व्यू इसे पा सकता है।

इसका तात्पर्य यह है कि व्यू किसी तरह व्यूमॉडल से जुड़ा हुआ है, जैसा कि उदाहरण के लिए एक फ़ंक्शन तर्क के रूप में इसे पुनः प्राप्त करने का विरोध किया गया है (जैसा कि डीटीओ के साथ मामला होगा)।

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

यदि यह न तो DTO है और न ही MVVM से ViewModel है, तो कृपया बताएं कि यह क्या है।

Comments

मुझे लगता है कि उत्तर "यह निर्भर करता है।" यदि यह एक वेब एप्लिकेशन है तो एक व्यू मॉडल मूल रूप से डीटीओ है क्योंकि यह अंततः HTML स्ट्रिंग के रूप में क्रमबद्ध हो जाता है। अन्यथा दृश्य मॉडल डेटा को दृश्य में प्रदर्शित करने के लिए एक विशेष वस्तु है।

— ग्रेग बरगार्ड

MVVM (WPF, Winforms अनुप्रयोगों) के ViewModelलिए आवरण है Controller, Presenterऔर ViewModelअंकल बॉब की स्वच्छ वास्तुकला में।

— फेबियो

@Greg बर्घर्ट - जब ViewModel एक विशेष डेटा संरचना है, तो व्यू में परिवर्तन की सूचना कैसे दी जाती है?

— फर्नबस्टर

@ फैबियो - अगर मैं आपके अर्थ को सही ढंग से कहता हूं कि एमवीवीएम पैटर्न में, ViewModel उन सभी घटकों के बराबर है जो आरेख के बाएं सबसे समूह के भीतर हैं? यदि यह अंकल बॉब की वास्तुकला के लिए सच है, तो वह नियंत्रक और प्रस्तुतकर्ता को अलग से क्यों सूचीबद्ध करता है?

— फर्नबस्टर

मुझे लगता है कि उसने इनपुट और आउटपुट हैंडलर को अलग-अलग ऑब्जेक्ट / कक्षाओं में अलग कर दिया। MVVM में यह हो सकता है Controller-> ICommandऔर Presenter-> data-binding mechanism।

— Fabio

Answer 1

क्या यह मॉडल-व्यू-व्यूमॉडल (MVVM) डिज़ाइन पैटर्न से 'व्यूमॉडल' के समान है

नहीं।

यही कारण है कि हो सकता है यह :

वह चक्र है। चाचा बॉब ध्यान से साइकिल से बचते रहे हैं ।

इसके बजाय आपके पास यह है:

जो निश्चित रूप से चक्र नहीं है। लेकिन इसकी आपको यह सोचकर छोड़ देता है कि किसी अपडेट के बारे में दृश्य कैसे जानता है। हम एक पल में मिल जाएगा।

या यह एक साधारण डेटा ट्रांसफर ऑब्जेक्ट (DTO) है?

पिछले पृष्ठ से बॉब को उद्धृत करने के लिए:

आप चाहें तो बेसिक स्ट्रक्चर्स या सिंपल डेटा ट्रांसफर ऑब्जेक्ट्स का उपयोग कर सकते हैं। या आप इसे एक हैशमैप में पैक कर सकते हैं, या एक ऑब्जेक्ट में इसका निर्माण कर सकते हैं।

साफ वास्तुकला p207

तो, यकीन है, अगर आप की तरह।

लेकिन मैं दृढ़ता से संदेह है कि क्या वास्तव में तुम गुस्सा दिलाना है है इस :

UML का यह प्यारा सा दुरुपयोग नियंत्रण के प्रवाह की दिशा के साथ स्रोत कोड निर्भरता की दिशा के विपरीत है। यह वह जगह है जहाँ आपके प्रश्न का उत्तर मिल सकता है।

एक प्रयोग संबंध में:

नियंत्रण का प्रवाह उसी दिशा में जाता है जो स्रोत कोड निर्भरता करता है।

एक कार्यान्वयन संबंध में:

नियंत्रण का प्रवाह आम तौर पर विपरीत दिशा में जाता है जो स्रोत कोड निर्भरता करता है।

इसका मतलब है कि आप वास्तव में इसे देख रहे हैं:

आपको यह देखने में सक्षम होना चाहिए कि नियंत्रण का प्रवाह प्रस्तुतकर्ता से दृश्य में कभी नहीं होने वाला है।

ऐसे कैसे हो सकता है? इसका क्या मतलब है?

इसका अर्थ है कि या तो इसका स्वयं का धागा है (जो कि असामान्य नहीं है) या (@ ईओफ़ोरिक बिंदुओं के रूप में) नियंत्रण का प्रवाह कुछ और से दृश्य में आ रहा है जो यहां चित्रित नहीं है।

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

यदि दृश्य का अपना धागा है तो उसका अपना नियंत्रण है। इसका मतलब है कि इसे लागू करने के लिए व्यू में बदलाव देखने के लिए व्यू-मॉडल को परागित करना होगा।

चूंकि प्रस्तुतकर्ता को पता नहीं होता है कि दृश्य मौजूद है और दृश्य प्रस्तुतकर्ता को नहीं जानता है कि वे एक-दूसरे को कॉल नहीं कर सकते हैं। वे एक-दूसरे पर घटनाओं को नहीं उछाल सकते। यह सब हो सकता है प्रस्तुतकर्ता दृश्य-मॉडल को लिखेगा और दृश्य दृश्य-मॉडल को पढ़ेगा। जब भी ऐसा लगे।

इस आरेख के अनुसार केवल दृश्य और प्रस्तुतकर्ता साझा दृश्य-मॉडल का ज्ञान है। और यह सिर्फ एक डेटा संरचना है। तो यह किसी भी व्यवहार की उम्मीद नहीं है।

यह असंभव लग सकता है लेकिन व्यू-मॉडल के जटिल होने पर भी इसे काम किया जा सकता है। एक छोटा सा अद्यतन क्षेत्र है सभी दृश्य एक परिवर्तन का पता लगाने के लिए चुनाव करना होगा।

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

यहाँ थोड़ा मज़ा है जो मैंने नियंत्रण के प्रवाह को दर्शाया था:

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

इसके अलावा यहाँ सीखने वाली एक और बात यह है कि यूज़ केस इंटरएक्टर उस चीज़ को कॉल कर सकता है, जिसे वह जितनी देर चाहे प्रेजेंटर को आखिरी बार बुलाए।

Comments

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

— फर्नबस्टर

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

— कैंडिड_ऑरेंज

ठीक है, मदद के लिए बहुत बहुत धन्यवाद। यदि आप इस वास्तुकला का पालन करते हैं, तो क्या यह तकनीक है जिसे आप आमतौर पर उपयोग करते हैं?

— फार्न्सबस्टर

मुझे लगता है कि बड़ी गलती है कि यह उत्तर समूह एक साथ निर्भरता और रनटाइम निर्भरता को डिजाइन करते हैं। दोनों अलग हो सकते हैं।

— युफ़ोरिक

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

— कैंडिड_ओरेंज

Answer 2

मुझे यह समस्या बहुत भ्रामक लगती है और इस समस्या को ठीक से समझाने में बहुत सारा पाठ और समय लगेगा क्योंकि मेरा मानना ​​है कि आप मार्टिन के क्लीन आर्किटेक्चर और एमवीवीएम दोनों को गलत समझ रहे हैं।

पहली बात ध्यान दें, यह है कि आपके द्वारा पोस्ट किया गया आरेख अधूरा है। यह केवल "व्यावसायिक तर्क" दिखाता है, लेकिन कुछ प्रकार के "ऑर्केस्ट्रेटर" को याद कर रहा है जो वास्तव में भागों को सही क्रम में स्थानांतरित करता है।

ऑर्केस्ट्रेटर का कोड जितना सरल होगा

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

मेरा मानना ​​है कि मैंने मार्टिन को क्लीन आर्किटेक्चर के बारे में अपनी एक वार्ता में इस बारे में बात करते हुए सुना।

एक और बात यह है कि कैंडिड_ऑरेंज की साइकिल की कमी के बारे में टिप्पणी गलत है। हां, कोड के आर्किटेक्चर में साइकल मौजूद नहीं है (और ऐसा नहीं होना चाहिए)। लेकिन रनटाइम इंस्टेंस के बीच चक्र आम हैं और अक्सर सरल डिजाइन के लिए नेतृत्व करते हैं।

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

मार्टिन की क्लीन आर्किटेक्चर से आपको जो सबसे महत्वपूर्ण चीज लेनी चाहिए, वह खुद डिजाइन नहीं है, लेकिन आप निर्भरता कैसे संभालते हैं। उनकी बातों में जो एक महत्वपूर्ण बिंदु है, वह यह है कि जब कोई सीमा होती है, तो सभी कोड निर्भरताएं उस सीमा को पार करते हुए एकल दिशा में पार करती हैं। आरेख में, इस सीमा को डबल लाइन द्वारा दर्शाया गया है। और वहाँ इंटरफेस के माध्यम से निर्भरता उलट के बहुत सारे है ( InputBoundary, OutputBoundaryऔर DataAccessInterface) है कि सुधारों कोड निर्भरता दिशा।

ViewModelक्लीन आर्किटेक्चर में इसके विपरीत बिना किसी तर्क के सिर्फ सादे डीटीओ हैं। यह <DS>टैग द्वारा स्पष्ट किया जाता है । और यही कारण है कि orchestratorयह आवश्यक है, क्योंकि Viewयह पता नहीं चलेगा कि इसे कब चलाना है।

अगर मैं आरेख को "समतल" करने के लिए था, तो यह रनटाइम के दौरान कैसा दिखेगा, यह इस तरह दिखेगा:

तो रनटाइम के दौरान, निर्भरता "गलत" दिशा में है, लेकिन यह ठीक है।

मैं तर्क को बेहतर ढंग से समझने के लिए क्लीन आर्किटेक्चर के बारे में उनकी बात देखने की सलाह देता हूं ।

Comments

आपके "ऑर्केस्ट्रेटर" को प्रस्तुतकर्ता को नहीं बुलाया जाना चाहिए। उपयोग केस इंटरेक्टर वह करता है।

— कैंडिड_ऑरेंज

@candied_orange सच, यह एक गलती है।

— व्योम

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

— फर्नबस्टर

@Fearnbuster अपने अंतिम प्रश्न के लिए, हाँ। निर्भरता की दिशा संरचना की तुलना में अधिक महत्वपूर्ण है। मेरा मानना ​​है कि "स्वच्छ वास्तुकला", "प्याज वास्तुकला" और "हेक्सागोनल वास्तुकला" वास्तव में "चेक में निर्भरता बनाए रखें" के एक ही विचार के कार्यान्वयन हैं।

— जश्न

@ यूफोरिक ईमानदारी से, मैं कहूंगा कि यह संभावना है, क्योंकि उनकी पुस्तक (अध्याय 8 के चित्र 8.2) की एक अलग छवि में, वह एक वास्तुकला दिखाता है जो अलग दिखता है। उस आरेख में, नियंत्रक वास्तव में अंतःक्रियात्मक और प्रस्तुतकर्ता के बीच एक मध्य-व्यक्ति है। इंटरेक्टर के लिए कोई आउटपुट बाउंड्री भी नहीं है; ऐसा लगता है कि सहभागिता इंटरफ़ेस के माध्यम से अनुरोध प्राप्त करता है, और फिर उसी इंटरफ़ेस के माध्यम से प्रतिक्रियाएं लौटाता है (मुझे लगता है कि यह एक साधारण फ़ंक्शन रिटर्न मान के माध्यम से किया जाता है, क्योंकि मैं किसी भी अन्य तंत्र के बारे में नहीं सोच सकता जो उस तरह से काम करेगा)।

— फेयरबस्टर