ऊपरी स्तर का दृश्य वास्तुकला। यांडेक्स व्याख्यान

सही वास्तुकला का चयन फ्रंट-एंड सेवा के निर्माण का एक महत्वपूर्ण हिस्सा है। डेवलपर एना कारपलेविच ने स्कूल ऑफ इंटरफेस डेवलपमेंट में छात्रों को बताया कि आर्किटेक्चर क्या है, यह क्या कार्य करता है और यह किन समस्याओं को हल करता है। व्याख्यान से आप फ्रंट-एंड में सबसे लोकप्रिय वास्तुशिल्प दृष्टिकोण के बारे में जान सकते हैं: मॉडल-व्यू- * और फ्लक्स।


- शुभ संध्या। मेरा नाम अन्या करपलेविच है। आज हम शीर्ष-स्तरीय फ्रंट-एंड की वास्तुकला के बारे में बात करेंगे।

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

वास्तुकला क्या है? तथ्य यह है कि इस सवाल का कोई जवाब नहीं है। या वहाँ है, लेकिन प्रत्येक का अपना है। यह बहुत विवादास्पद विषय है। यह बहुत विवाद का कारण बनता है, बहुत सारे होलीवर। और आज मैं जिस बारे में बात करूंगा उसका बहुत कुछ मेरा मत है। आंशिक रूप से यह मेरे काम करने वाले समूह द्वारा समर्थित है, आंशिक रूप से बहुत ज्यादा नहीं। और हर कोई, जब वह अपने आवेदन की वास्तुकला लिखता है, तो अपने लिए निर्णय लेता है कि कैसे और क्या करना है।

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



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

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

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

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

इस रचनात्मक परिचय के साथ, हम अंत करते हैं, अधिक सांसारिक चीजों पर आगे बढ़ते हैं, निर्माण अनुप्रयोगों के अभ्यास के करीब।

वास्तुकला क्या है और इसकी आवश्यकता क्यों है?



सबसे पहले, हमारे पास बड़ी मात्रा में कोड का संगठन है, कुछ ऐसा जो हम डायरेक्ट में करते हैं, और सिर्फ डायरेक्ट में नहीं, हर समय मुठभेड़ करते हैं। इतना कोड है कि आप इसमें खो सकते हैं। हम कोड में खो जाना नहीं चाहते हैं।

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

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

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

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

और अंत में, त्रुटियाँ। हमारी वास्तुकला जितनी अधिक समझ में आने वाली है, त्रुटियों को देखने में उतनी ही आसान है, कम बग।

यह सब कैसे कहा जा सकता है? यह सब कहा जा सकता है - एक जटिल प्रणाली की समस्याएं। एक आवेदन एक जटिल प्रणाली है, वास्तुकला हमें एक समस्या को हल करने में मदद करता है।



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



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

ज्ञान के क्षेत्र के रूप में अनुप्रयोग वास्तुकला की विशेषताएं क्या हैं? उसके पास एक विशिष्ट क्षेत्र है जिसके साथ हम काम करते हैं। यही है, यह कुछ सार नहीं है, यह एक बहुत विशिष्ट बात है। यहाँ कार्य है, हम इसके लिए वास्तुकला का चयन करते हैं, और ऐसा नहीं है, ऊह, एक दिलचस्प वास्तुशिल्प दृष्टिकोण, हमें कोशिश करनी चाहिए। तो, नहीं। आप कुछ छोटे पर कोशिश कर सकते हैं, लेकिन एक गंभीर परियोजना के लिए, वास्तुकला का चयन किया जाता है, कभी-कभी एक विशिष्ट परियोजना के लिए बनाया जाता है।

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

70 के दशक में, यह विचार पहले से ही डायनासस्ट्रा द्वारा पर्नासस के साथ, और अपने दम पर, व्यक्तिगत रूप से विकसित किया गया था। सामान्य रूप से आवेदन वास्तुकला पर पहली विस्तृत पुस्तक 1996 में मैरी शॉ और डेविड गरलन द्वारा लिखी गई थी। उसके बाद, वास्तव में, सॉफ्टवेयर आर्किटेक्चर के बारे में इस तरह की विस्तृत पुस्तकों को गुंजाइश के कारण ठीक से नहीं लिखा गया था, कि ज्ञान के प्रत्येक क्षेत्र के अपने वास्तुशिल्प दृष्टिकोण हैं, कहीं एक, कहीं और अधिक लोकप्रिय, कुछ, आम तौर पर कुछ स्थानों पर लागू नहीं है। और चूंकि वास्तुकला एक रचनात्मक प्रक्रिया है, इसलिए आपको आर्किटेक्चर लिखने के बारे में कोई विशिष्ट किताबें नहीं मिली हैं। शायद १ ९९ ६ के बाद इस विषय पर विशेष रूप से विस्तृत कुछ नहीं था

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

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

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

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

आगे हम आपके साथ कुछ परिभाषाओं के बारे में बात करेंगे, ऐसी ही विश्वकोशीय बातें। यह महत्वपूर्ण क्यों है? क्योंकि वास्तुकला में शब्दावली बहुत महत्वपूर्ण है, और हमें आपके साथ एक ही भाषा बोलने की आवश्यकता है। अधिकांश भाग की परिभाषाएँ प्रोग्रामिंग प्रतिमान से ली गई हैं जिन्हें OOP कहा जाता है। लेकिन वास्तव में, वे अन्य प्रतिमानों में बदल गए हैं, शर्तों के साथ "वर्ग, वस्तु, इंटरफ़ेस" वे न केवल ओओपी के ढांचे के भीतर काम करते हैं। हालाँकि, इन परिभाषाओं और समझ को OOP की दुनिया से ठीक लिया गया है।



सबसे सरल चीज कक्षा है। कक्षा क्या है? यह एक टेम्पलेट है, यह एक नमूना है। उदाहरण के लिए, स्नेक क्लास क्लास स्नेक है। हमने उसके साथ तीन निजी क्षेत्रों को परिभाषित किया है, वह है, एक ऐसा क्षेत्र जो किसी के लिए भी सुलभ नहीं है, केवल कक्षा के तरीकों को छोड़कर - लक्ष्यों की संख्या, पूंछ की संख्या और तोते की लंबाई। हमने कंस्ट्रक्टर निर्धारित किया जिसमें हम तोते में ये ही सिर, पूंछ और लंबाई डालते हैं। सांप की क्लास लग गई। सब कुछ सरल है।



हम और आगे जा रहे हैं। वस्तु। और एक वस्तु एक विशिष्ट संरचना का एक उदाहरण है। इसके अलावा, फिर से शास्त्रीय OOP में यह निहित है कि एक वस्तु एक वर्ग की एक वस्तु है। आधुनिक दुनिया में, जावास्क्रिप्ट में, जो हमेशा एक ओओपी भाषा नहीं थी, और अब भी यह हमेशा और हर जगह ओओपी नहीं है, हम जानते हैं कि अमूर्त वस्तुएं हो सकती हैं। यही है, हम एक ऑब्जेक्ट बना सकते हैं, एक शाब्दिक, जो क्लास का ऑब्जेक्ट नहीं होगा। लेकिन यहाँ एक उदाहरण है कि हम स्नेक वर्ग की वस्तु कैसे बनाते हैं। यहां हमारे पास 38 तोतों की लंबाई के साथ दो पूंछ वाला सांप है, - एक बोआ कंस्ट्रक्टर।



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



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



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

और जब हम इंटरफ़ेस बनाते हैं, तो हम वह करते हैं जो वह करता है, वह क्या करने में सक्षम होना चाहिए। और यह कक्षाओं के विस्तार के लिए एक बहुत शक्तिशाली तरीका साबित होता है। हम कक्षाओं को कुछ वर्गों के लिए विशेषता दे सकते हैं, इसे इंटरफेस की मदद से विस्तारित कर सकते हैं। उदाहरण के लिए, I-BEM फ्रेमवर्क ऐसा काम कर सकता है, अमूर्त इंटरफेस वाली ऐसी कहानी को फ्रेमवर्क में बनाया गया है। दुर्भाग्य से, कई रूपरेखाओं को नहीं पता कि कैसे, और बात शक्तिशाली है।

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

अब हम इन उदाहरणों को थोड़ा और विशेष रूप से देखने का प्रयास करेंगे।



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

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

आइए देखें कि हम किस तरह के बिंदुओं पर मजबूत कर्षण और कमजोर युग्मन प्राप्त कर सकते हैं।



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

वही बात, अमूर्तता। यह कार्यान्वयन से इंटरफ़ेस के अमूर्त होने के बारे में है। विचार यह है कि इंटरफ़ेस बाहरी है, हमारा वर्ग कैसा है, हमारा ब्लॉक बाहर है, यह अन्य ब्लॉकों के साथ कैसे इंटरैक्ट करता है, यह आपके आंतरिक कार्यान्वयन को प्रभावित नहीं करता है। इसके विपरीत - ऐसा होता है। दूसरा तरीका - कभी नहीं। एक अच्छे आर्किटेक्चर में। यहाँ, एक उदाहरण के रूप में, इन फुंसियों के बनने से ब्लॉक के आकार पर कोई असर नहीं पड़ता है। हम ब्लॉक के आकार को अलग से चुनते हैं और पहले से ही उस पर गोंद चिपकाते हैं।



Encapsulation। पिछले विषय की निरंतरता। निजी तरीकों में, अर्थात्, हमारे ब्लॉकों के भीतर से, हमें अपने ब्लॉक, कार्यान्वयन के बहुत अर्थ का एहसास होता है। और इंटरफ़ेस, जिस तरह से वे जुड़े हुए हैं, सार्वजनिक रूप से है। यही है, इस मामले में, ये सभी क्रॉस, डैश और फॉर्म ही कार्यान्वयन हैं। और pimples इंटरफ़ेस हैं। और अच्छी वास्तुकला ऐसे निर्माता की तरह दिखती है।



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

क्या विचार है? यदि आपके पास एक ऊंट के लिए एक कार्यान्वयन और एक मगरमच्छ के लिए एक कार्यान्वयन है, और एक प्रबंधक आपके पास आता है और कहता है कि ऊंट-मगरमच्छ की तत्काल आवश्यकता है। आप एक ऊंट मगरमच्छ को अलग से नहीं लिखते हैं। आप ऊंट के शरीर को लेते हैं, इसे ऊंट के पूरे अहसास से अलग करते हैं। मगरमच्छ के सिर को लें, इसे मगरमच्छ से अलग करें, और ब्लॉकों का पुन: उपयोग करें। यह क्यों आवश्यक है?

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

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



- . , . TypeScript, . , . , , , TypeScript 2.7 , ( — . .).

, User. . . User , . User , , .

printLabel. User. , User User, . User User , , . - , .

, ? , . , . , − , UserWithSurname, , printLabel. ? , , , , . - ? , . , − , . . PrintLabel . ? ? , .

, . , . , , . , if, , . , , .



printLabel, , iPrintLabel , iPhone, . - getText. User, iPrintLabel. , , , - , getText iPrintLabel, , . UserWithSurname, User, Surname getText. printLabel . iPrintLabel getText.

, , , . . , , . , , , , , iPrintLabel, , , , − . printLabel . , .

. , , , front-end, , . , front-end , , .



-? . - back-end. - API, , REST API REST. — , − -. , , - PowerPoint, . .

front-end. Front-end - . - , . , - . . . , -, . , , . .

front-end, , , , , , , .

> - ( Client-server )
> ( Component-based )
> ( Event-driven )
> REST ( Representational state transfer )
> --*( MVC , MVP , MVVM )
> ( Flux )

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

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

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



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



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

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

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



बहुत सरल है। यदि नियंत्रक और मॉडल बैक-एंड में हैं, और टेम्प्लेटिंग व्यू सर्वर-साइड है। इस तरह से रूबी ऑन रेल्स, ASP.NET, Django के फ्रेमवर्क को व्यवस्थित किया जाता है, जहाँ भी आप सर्वर-साइड टेम्प्लेटिंग लिखते हैं, और एकत्रित HTML क्लाइंट के पास आता है, और डेटा भी उच्च संभावना के साथ वापस चला जाता है, यह दृष्टिकोण है। यहां क्या समस्याएं हैं। एक पृष्ठ के आवेदन में, इस तरह की चीज का निर्माण नहीं किया जा सकता है। हमारे पास सर्वर पर लगातार डेटा होता है, सर्वर पर चला जाता है, पेज पुनः लोड होता है। दूसरे, यह पूरी तरह से स्पष्ट नहीं है कि ग्राहक सत्यापन को कहां से खदेड़ना चाहिए, और, सामान्य रूप से, ग्राहक जावास्क्रिप्ट, AJAX और यह सब यहाँ? क्योंकि अगर हमें कुछ जल्दी चाहिए, तो कहीं नहीं। यह बस इस दृष्टिकोण में काम नहीं करता है, या काम करता है ताकि यह बेहतर काम न करे।

यहां अंतिम पंक्ति, यह ऐसी दिलचस्प कहानी है, निहित है, ऐसा लगता है, 2008 में। सवाल यह था: व्यापार तर्क को कहां स्टोर करना है - मॉडल पर या नियंत्रक में? ऐसे लोग थे जिन्होंने कहा: "हम नियंत्रक में व्यावसायिक तर्क संग्रहीत करते हैं, क्योंकि यह सुविधाजनक, तुरंत स्वच्छ डेटा मॉडल पर भेजा जाता है। नियंत्रक स्वयं को मान्य करेगा, पुनरावृत्ति करेगा, यदि कुछ भी हो, और एक त्रुटि भेजें। " ऐसे लोग थे जिन्होंने कहा था कि "परिणाम वसा बेवकूफ बदसूरत नियंत्रक, मोटा गूंगा, बदसूरत नियंत्रक है।" वे वास्तव में विशाल निकले। और उन्होंने कहा कि व्यापार तर्क मॉडल में होना चाहिए, और नियंत्रक को पतला, हल्का, डेटा स्थानांतरित करना चाहिए, मॉडल स्वयं संसाधित होता है। और फिर पहले संस्करण में, मॉडल, सामान्य रूप से, डेटाबेस के लिए केवल एक एपीआई बन जाता है।

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

मुझे यह कहना चाहिए कि दुनिया ने मॉडल में व्यावसायिक तर्क के साथ दूसरे दृष्टिकोण से जीत हासिल की है। यही है, इन वसा बेवकूफ बदसूरत नियंत्रकों को इतनी सक्रिय रूप से उपयोग नहीं किया जाता है। सिग्नल, आप देख सकते हैं कि ASP.NET के लिए प्रलेखन में क्या है, 2013 में वापस रूपरेखा ने नियंत्रकों में व्यावसायिक तर्क का प्रस्ताव दिया। और 2014 में नवीनतम संस्करणों में - मॉडल में। एक बहुत ही दिलचस्प क्षण था जब यह बदल गया।

MVC को क्या समस्या है हम उन्हें पहले ही बोल चुके हैं, लेकिन हम करेंगे। परीक्षण के रूप में यह स्पष्ट नहीं है कि क्लाइंट सत्यापन को कैसे लागू किया जा सकता है, लेकिन मुश्किल है, AJAX की ओर से पेंच है, आपको कुछ करने की आवश्यकता है। वे समाधान लेकर आए। समाधान को एमवीपी कहा जाता था, और, हां, आप एमवीपी को इस पाठ के साथ मिल सकते हैं कि वे एमवीसी हैं। उदाहरण के लिए, बैकबोन एमवीपी फ्रेमवर्क। उसी 2011-2012-2013 के दस्तावेज में उसके बारे में लंबे समय तक यह लिखा गया था कि यह एमवीसी ढांचा है।



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



आइए तुलना करते हैं। आइए पहली तस्वीर देखें, जहां हम एक बहुत ही साधारण चीज को लागू करने की कोशिश करेंगे - मॉडल से इनपुट से डेटा भेजना। हमने कुछ दर्ज किया, एक बटन क्लिक किया, यह मॉडल में दिखाई देना चाहिए, मॉडल इसके साथ कुछ करेगा और हमें बताएगा कि कुछ हुआ। हम में चले गए: "मेरा नाम वास्या है", ठीक क्लिक किया। यदि हम क्लाइंट-साइड सत्यापन चाहते हैं, तो यह यहां होता है, लगभग अंतरविरोध द्वारा, विशेष रूप से गंभीर मामलों में, वास्तव में, event.preventDefault () के माध्यम से एक क्लिक को इंटरसेप्ट करके। और कहीं, साइड बोल्ड क्लाइंट सत्यापन पर एक बिंदु शून्य।

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

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

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

यहां प्लस क्या है जेएस सत्यापन अपने सही स्थान पर गिर गया और इसके साथ सब कुछ ठीक हो गया, AJAX भी जगह में गिर गया, यह चौथा तीर हो सकता है, उदाहरण के लिए, यदि मॉडल सर्वर पर है, या मॉडल AJAX स्वयं सर्वर पर जाता है। और अंत में, हम सुरक्षित रूप से प्रस्तुतकर्ता का परीक्षण कर सकते हैं, उस पर कार्यात्मक परीक्षण लिख सकते हैं।



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

क्या विशेषताएं हैं प्रस्तुतकर्ता को पहले से ही क्लाइंट पर रखा गया है, मॉडल वहां हो सकता है, और वहां एकल पृष्ठ अनुप्रयोग चुपचाप किए जाते हैं। यह बेहतर होता है, लेकिन इस कहानी पर बहुत सारे एकल पृष्ठ अनुप्रयोग हैं, या कम से कम यह पहले किया गया है। AJAX सर्वर इंटरेक्शन अच्छा है। जगह में ग्राहक सत्यापन। ऐसा लगता है कि सब कुछ ठीक है, आगे क्यों सोचते हैं?

हालांकि, कम से कम MVVM का आविष्कार किया गया था। साथ ही एक दिलचस्प बात।



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



और इतने सारे ढांचे ने सिर्फ इन बाध्यकारी कार्यों को हल किया। क्या फायदे हैं? हमें अतिरिक्त कोड लिखने की आवश्यकता नहीं है। और यह वास्तव में विकास की गति को तेज करता है। क्या नुकसान हैं। मॉडल और ViewModel के बीच कनेक्टिविटी बढ़ जाती है।

यही है, मजबूत कनेक्टिविटी की वजह से समस्याएं ठीक होती हैं, इसलिए कभी-कभी ऐसा होता है कि एमवीवीएम का उपयोग नहीं किया जाता है। उदाहरण के लिए, मैं व्यक्तिगत रूप से i-BEM ढांचे में MVVM से परिचित हूं, जिसका उपयोग हम कभी-कभी करते हैं, और कभी-कभी उपयोग नहीं करते हैं, क्योंकि यह एक असुविधाजनक, बहुत तंग बंधन है। हालांकि, वहाँ है, माइक्रोसॉफ्ट सिल्वरलाइट इस तकनीक द्वारा व्यवस्थित है, और वे कहते हैं: अच्छा। मुझे नहीं पता, मैंने इसकी कोशिश नहीं की है।

ऐसा क्यों हुआ कि एमवीपी और एमवीवीएम के अलावा, कुछ और उत्पन्न हुआ, आप सभी को रिडक्स शब्द से परिचित होना चाहिए, क्यों यूनिडायरेक्शनल डेटा स्ट्रीम थे।



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

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

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



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

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

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



यहां एक लेबल और एक बटन के साथ हमारा फॉर्म है। वह कैसे काम करती है? हम बिंदु शून्य को देखते हैं। प्वाइंट जीरो यहां भी है। वह बहुत नीचे स्थित नीला तीर है, कॉलबैक पंजीकरण। पहले ऐसा होता है।

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

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

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

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



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

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

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

फ्लक्स वास्तुकला के साथ संयुक्त अनुप्रयोग शक्तिशाली हैं। शायद, बहुत से लोग जानते हैं कि यह वास्तव में एक शक्तिशाली चीज है। क्या कुछ महत्व है जिसका उल्लेख किया जाना चाहिए? रिएक्ट रेडक्स के अलावा, कई अन्य बंडल हैं। और आप शायद जानते हैं कि एक दूसरा कोणीय है। यह प्रतिक्रियाशील ढांचे और फ्लक्स वास्तुकला का एक संयोजन भी है। Vue, Flux Redux — Fluxxor, MobX . . React Redux. Vue, , , React Redux. .



? , React Redux . Vue, . — . — MVC-. . . - React Redux .

MVP/MVVM- . , — , , . single page application, multiple page application. - - . , -, - . , MVP, .

— single page application , , . . Flux React Redux, View, Angular, MobX, Fluxxor . .

. .

> MVC: Smalltalk-80 , General MVC , ASP.NET , MVC on Web
> MVP: MVP vs MVC , GUI Architecture , Backbone , Angular1
> MVVM: MS Silverlight , i-BEM
> Flux: Hexlet , Flux for stupid people , Flux official , ReactJS , VueJS
> : , «Javascript. » , ., « » , D.Garlain, M.Shaw, ”An introduction to Software Architecture” (1994), E.Dijkstra ”GOTO statement considered harmful” (1968)

MVC, MVP, MVVM . , . Flux . , , . , — . . JavaScript. . ES5, «JavaScript. » , ES6- — , , , .

, « ». . Java, . , , Flux, . MVP, — -. , . .

, , « ». , , , , , . «GOTO operator considered harmful». . , .

. . . , - , . , , Flux, , input Flux. — , , - . . , . , . .