एक जटिल ग्राहक अनुप्रयोग के निर्माण के लिए कार्यप्रणाली के तीन दृष्टिकोण

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

विशेष रूप से संभावना है, साइकिल का आविष्कार, जब आवेदन की जटिलता में वृद्धि धीरे-धीरे और एक अर्थ में स्पष्ट रूप से होती है। एक जटिल अनुप्रयोग आमतौर पर एक समृद्ध अनुप्रयोग होता है, इसके तत्व और विशेषताएं W3C www.w3.org/TR/backplane द्वारा निर्दिष्ट की जाती हैं। जाने-माने JavaScript के प्रचारक Addy Osmani ने एक जटिल एप्लिकेशन को आगे परिभाषित करते हुए कहा: "मेरी राय में, एक बड़ा JavaScript एप्लिकेशन एक गैर-तुच्छ एप्लिकेशन है जिसे समर्थन करने के लिए महत्वपूर्ण डेवलपर प्रयासों की आवश्यकता होती है, और ब्राउज़र के साथ डेटा को संसाधित करने और प्रदर्शित करने के लिए सबसे कठिन संचालन होता है" (http: // addyosmani)। com / largescalejavascript /)।


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

मैं इसे इतना सामान्य नहीं देखता, भले ही यह कितना भी सामान्य क्यों न हो। इसके बजाय, मैं कई अलग-अलग अवधारणाओं को देखता और समझता हूं। पहला प्रसिद्ध एमवीसी (मॉडल व्यू कंट्रोलर) डिजाइन योजना है। दूसरा निकोलस ज़कस (याहू सम्मेलन www.youtube.com/watch?v=vXjVFPosQHw पर बोलते हुए) से तार्किक कोड पृथक्करण की अवधारणा है।
तीसरा कोड बनाने के लिए एक भोली दृष्टिकोण है जहां डेटा मिलाया जाता है, इंटरफ़ेस तत्वों और विभिन्न कार्यों के साथ काम करना (मिश्रण "पास्ता" में दुखद परिणाम हो सकता है)।

इसके अलावा, एक ठीक रेखा यह सवाल है कि इन दृष्टिकोणों में कोड का संगठन क्या है और कार्यक्षमता का संगठन क्या है।

MVC स्कीम (मॉडल रिप्रेजेंटेशन कंट्रोलर) को कई सफल जावास्क्रिप्ट कार्यान्वयन मिले: बैकबोन.जेएस, जावास्क्रिप्टएमवीसी। संक्षेप में योजना के बारे में। मॉडल में उनकी संरचना और पदानुक्रम में डेटा होता है। दृश्य इस डेटा के संस्करण का वर्णन करता है जो उपयोगकर्ता को प्रेषित होता है। मॉडल और दृश्य के बीच कोई सीधा संबंध नहीं है, इसके लिए एक नियंत्रक के रूप में एक मध्यस्थ है - यह घटनाओं का प्रबंधन करता है और एक एमवीसी मॉड्यूल (पदानुक्रमित एमवीसी योजना में) में कई दृश्यों या स्थानांतरण नियंत्रण का प्रबंधन कर सकता है।



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



MVVM को सिल्वरलाइट के लिए वर्णित किया गया है और इसमें एक निश्चित तर्क के साथ जटिल इंटरफेस के फायदे हैं जो एप्लिकेशन लॉजिक से भिन्न है (उदाहरण के लिए, जब मॉडल में कोई ऑब्जेक्ट जोड़ते हैं, तो एप्लिकेशन इंटरफ़ेस nontrivially बदल जाता है)। HTML के लिए, MVVM योजना DOM के लिए विशेष रूप से सफल है, जो कि आप जानते हैं, इसमें अच्छी तरह से डेटा हो सकता है। इसलिए MVVM को सफलतापूर्वक नॉकआउट.जेएस ढांचे में लागू किया गया था। प्रारंभ में, सब कुछ सरल है। सर्वर द्वारा प्रदान किया गया एक डेटा मॉडल है। DOM के रूप में मार्कअप के रूप में एक प्रतिनिधित्व है। और प्रतिनिधित्व-मॉडल है, जो प्रतिनिधित्व में परिवर्तन का वर्णन करता है, मॉडल और प्रस्तुति को जोड़ता है, और इस कनेक्शन को सिंक्रनाइज़ करता है।
यह ध्यान देने योग्य है कि एमवीसी की व्याख्या केवल आवेदन के तीन स्तरों के अलगाव के रूप में की जा सकती है, और किसी भी तरह से उनके बीच के रिश्ते को विनियमित नहीं करता है। इसलिए, अक्सर ऐसे आरेख होते हैं जिनमें मॉडल और दृश्य तीरों से जुड़े होते हैं, हालांकि यह स्पष्ट है कि इस तरह से अलग-अलग दृश्यों का उपयोग करते समय उपयोगी मापनीयता गुण और नियंत्रकों के पदानुक्रम खो जाते हैं। इसके बारे में अधिक जानकारी आईओएस www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259 के लिए विकासशील अनुप्रयोगों पर पहले पॉल हेगार्टी व्याख्यान में स्पष्ट रूप से बताई गई है।

निकोलस ज़कस ने अपने विकास प्रस्तावों को प्रस्तुत किया (पैटर्न की भाषा में उनकी औपचारिकता Addy Osmani addyosmani.com/largescalejavascript ) लेख में है। उन्होंने फैसला किया, वास्तव में, सामान्य मॉडल और तर्क से दूर होने के लिए, और "डिवाइड और विजय" एल्गोरिथ्म का उपयोग करें: एप्लिकेशन तत्वों को इंटरफ़ेस ब्लॉक से सजाया गया है, और प्रत्येक को अपने स्वयं के मॉड्यूल में लागू किया गया है। ये मॉड्यूल एक दूसरे के साथ आदान-प्रदान नहीं करते हैं। वे केवल सैंडबॉक्स के बारे में जानते हैं जिसमें वे निष्पादित होते हैं। सैंडबॉक्स, बदले में, आवेदन के मूल से संबंधित है, जो प्रक्रिया को लॉन्च करता है और कार्यों के अनुक्रम की निगरानी करता है। मूल खुद श्रृंखला में अंतिम नहीं है (कॉल): नीचे पर्यावरण के साथ तकनीकी काम के लिए मानक पुस्तकालय हैं, जैसे कि jQuery, प्लगइन्स के साथ। मॉड्यूलर अनुप्रयोगों के लिए, एक एएमडी मॉड्यूल विनिर्देश विनिर्देश (और वैकल्पिक सीजेएस) बनाया गया है।



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



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

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

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

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

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

मैं इस सतही विश्लेषण को गहरा करना चाहूंगा। मैंने किन बिंदुओं को गलत तरीके से दर्शाया? किन तरीकों का व्यापक वर्णन है? मैं सभी टिप्पणीकारों को MVC, MVVM, और प्रतिरूपता दृष्टिकोण के साथ अपने अनुभव साझा करने के लिए कहता हूं!

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


सूत्रों का कहना है

habrahabr.ru/blogs/webdev/117791
blog.rebeccamurphey.com/code-org-take-2-structuring-javascript-applic
addyosmani.com/largescalejavascript
nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm
www.w3.org/TR/backplane
एलेक्स मैकका, जावास्क्रिप्ट वेब एप्लीकेशन। jQuery डेवलपर्स गाइड टू स्टेट टू द क्लाइंट, 2011
www.youtube.com/watch?v=vXjVFPosQHw (वीडियो)
www.intuit.ru/depbox/internet/aspnetmvcframe/1 (वीडियो)
www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259 (iTunes, वीडियो)
blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated (php, मोटे नियंत्रकों की आलोचना)
martinfowler.com/eaaDev/uiArchs.html