अधिकांश (सभी के;) जिन रूपरेखाओं को आप देख रहे हैं, वही समस्याएं हल करती हैं, लेकिन वे इसे थोड़े अलग तरीके से अलग-अलग लक्ष्यों के साथ करते हैं।
मुझे लगता है कि यह कहना उचित है कि इन सभी परियोजनाओं से इन श्रेणियों में समस्याओं का समाधान होगा:
- चूक के समझदार सेट प्रदान करें
- बॉयलरप्लेट कोड को कम करें
- बैकबोनजेएस बिल्डिंग ब्लॉकों के शीर्ष पर एप्लिकेशन संरचना प्रदान करें
- ऐसे पैटर्न निकालें जो लेखक अपने ऐप में उपयोग करते हैं
मेरीओनेट, जो मैं 2011 के दिसंबर से बना रहा हूं, कुछ अलग लक्ष्य और आदर्श हैं, साथ ही:
- समग्र अनुप्रयोग वास्तुकला
- एंटरप्राइज मैसेजिंग पैटर्न प्रभाव
- संशोधन के विकल्प
- वृद्धिशील उपयोग (कोई सभी-या-कुछ भी आवश्यकता नहीं)
- कोई सर्वर लॉक-इन नहीं
- उन चूक को बदलना आसान बनाएं
- कॉन्फ़िगरेशन / ओवर कॉन्फ़िगरेशन के रूप में कोड
मैं यह नहीं कह रहा हूँ कि अन्य रूपरेखाओं में से कोई भी समान लक्ष्य नहीं है। लेकिन मुझे लगता है कि Marionette की विशिष्टता इन लक्ष्यों के संयोजन से आई है।
समग्र अनुप्रयोग वास्तुकला
मैंने 5 से अधिक वर्षों तक मोटी-क्लाइंट में काम किया, WinForms और C # का उपयोग करके सॉफ्टवेयर सिस्टम वितरित किया। मैंने डेस्कटॉप, लैपटॉप (स्मार्ट-क्लाइंट), मोबाइल डिवाइस और वेब एप्लिकेशन के लिए ऐप बनाए हैं, सभी एक कोर फंक्शनल सेट साझा कर रहे हैं और एक ही सर्वर के साथ कई बार काम करते हैं। इस समय में, मैंने मॉडर्लाइज़ेशन के मूल्य को सीखा और बहुत तेज़ी से कंपोज़िट एप्लिकेशन डिज़ाइन का एक पथ नीचे चला गया।
मूल विचार आपके एप्लिकेशन के रनटाइम अनुभव को "रचना" करना और कई छोटे, व्यक्तिगत टुकड़ों से बाहर निकालना है जो जरूरी नहीं कि एक दूसरे के बारे में जानते हों। वे समग्र समग्र अनुप्रयोग प्रणाली के साथ खुद को पंजीकृत करते हैं और फिर वे डिकॉय किए गए संदेशों और कॉल के विभिन्न माध्यमों से संवाद करते हैं।
मैंने अपने ब्लॉग पर इसके बारे में थोड़ा सा लिखा है, बैकबोन के लिए एक समग्र एप्लिकेशन आर्किटेक्चर के रूप में मैरियनट का परिचय देते हुए:
संदेश कतार / पैटर्न
समान बड़े पैमाने पर, वितरित सिस्टम ने संदेशों को संभालने के लिए संदेश कतारबद्धता, उद्यम एकीकरण पैटर्न (संदेश पैटर्न) और सेवा बसों का भी लाभ उठाया। यह, किसी भी चीज़ से अधिक, सॉफ्टवेयर विकास को डिकूप करने के लिए मेरे दृष्टिकोण पर एक जबरदस्त प्रभाव था। मैंने इस दृष्टिकोण से सिंगल-प्रोसेस, इन-मेमोरी विनफार्म्स एप्लिकेशन को देखना शुरू किया और जल्द ही मेरे सर्वर साइड और वेब एप्लिकेशन डेवलपमेंट ने इस पर प्रभाव डाला।
यह सीधे खुद में अनुवादित है कि मैं बैकबोन एप्लिकेशन डिज़ाइन को कैसे देखता हूं। मैं Marionette में एक इवेंट एग्रीगेटर प्रदान करता हूं, दोनों उच्च स्तरीय अनुप्रयोग ऑब्जेक्ट के लिए, और प्रत्येक मॉड्यूल के लिए जो आप एप्लिकेशन के भीतर बनाते हैं।
मैं उन संदेशों के बारे में सोचता हूं जो मैं अपने मॉड्यूल के बीच भेज सकता हूं: कमांड संदेश, घटना संदेश, और बहुत कुछ। मैं इन समान पैटर्न वाले संदेश के रूप में सर्वर साइड संचार के बारे में भी सोचता हूं। कुछ पैटर्न ने पहले से ही मैरियनट में अपना रास्ता बना लिया है, लेकिन कुछ ने अभी तक नहीं किया है।
modularization
कोड का मॉडर्नाइजेशन काफी महत्वपूर्ण है। छोटे, अच्छी तरह से समझाया गया पैकेज बनाना जिसमें अच्छी तरह से परिभाषित प्रविष्टि और निकास बिंदुओं के साथ एक विलक्षण फोकस है, किसी भी महत्वपूर्ण आकार और जटिलता के किसी भी सिस्टम के लिए आवश्यक है।
Marionette यह moduleपरिभाषाओं के माध्यम से सीधे तौर पर संशोधन प्रदान करता है । लेकिन मैं यह भी मानता हूं कि कुछ लोग जरुरज को पसंद करते हैं और उसका इस्तेमाल करना चाहते हैं। इसलिए मैं एक मानक बिल्ड और एक आवश्यकताJJ दोनों संगत बिल्ड प्रदान करता हूं।
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(इसके लिए अभी तक कोई ब्लॉग पोस्ट उपलब्ध नहीं है)
वृद्धिशील उपयोग
यह एक मुख्य दार्शनिक है जिसे मैं मैरियनट के हर हिस्से में सेंध लगाता हूं जो मैं कर सकता हूं: मैरियोनेट के उपयोग के लिए कोई "सभी-या-कुछ नहीं" आवश्यकता।
बैकबोन अपने आप में बहुत ही वृद्धिशील और मॉड्यूलर दृष्टिकोण लेता है, जिसमें सभी ब्लॉक ऑब्जेक्ट्स का निर्माण कर रहे हैं। आप यह चुनने के लिए स्वतंत्र हैं कि आप किसका उपयोग करना चाहते हैं, कब। मैं इस सिद्धांत में दृढ़ता से विश्वास करता हूं और यह सुनिश्चित करने का प्रयास करता हूं कि मैरियनेट उसी तरह काम करता है।
उस छोर तक, मैरियोनेट में मेरे द्वारा बनाए गए अधिकांश टुकड़े अकेले खड़े होने के लिए, बैकबोन के मुख्य टुकड़ों के साथ काम करने के लिए और बेहतर तरीके से एक साथ काम करने के लिए बनाए गए हैं।
उदाहरण के लिए, लगभग हर बैकबोन एप्लिकेशन को गतिशील रूप से स्क्रीन पर किसी विशेष स्थान पर बैकबोन दृश्य दिखाने की आवश्यकता होती है। जब कोई नया स्थान डाला जाता है तो ऐप को पुराने दृश्यों को बंद करने और स्मृति को साफ करने की भी आवश्यकता होती है। यह वह जगह है जहाँ मैरियनेट Regionखेलने के लिए आता है। एक क्षेत्र एक दृश्य लेने के बॉयलरप्लेट कोड को संभालता है, उस पर रेंडर कॉल करता है, और परिणाम को आपके लिए डोम में भरता है। फिर उस दृश्य को बंद कर देगा और आपके लिए इसे साफ कर देगा, बशर्ते आपके विचार में इस पर "करीब" विधि हो।
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
लेकिन एक क्षेत्र का उपयोग करने के लिए आपको मैरियनेट के विचारों का उपयोग करने की आवश्यकता नहीं है। केवल आवश्यकता यह है कि आप ऑब्जेक्ट के प्रोटोटाइप चेन में कुछ बिंदु पर Backbone.View से विस्तार कर रहे हैं। यदि आप एक closeविधि, एक onShowविधि, या अन्य प्रदान करने के लिए चुनते हैं, तो Marionette का क्षेत्र आपके लिए सही समय पर कॉल करेगा।
कोई सर्वर लॉक-इन नहीं
मैं सर्वर तकनीकों की एक विस्तृत विविधता के शीर्ष पर बैकबोन / मैरियनेट एप्लिकेशन बनाता हूं:
- ASP.NET MVC
- रूबी ऑन रेल्स
- रूबी / सिनात्रा
- NodeJS / एक्सप्रेसजेएस
- PHP / स्लिम
- जावा
- Erlang
- ... और अधिक
जब यह ब्राउज़र में चलने की बात आती है, तो जावास्क्रिप्ट ही जावास्क्रिप्ट है। सर्वर साइड जावास्क्रिप्ट बहुत बढ़िया है, लेकिन इसका शून्य प्रभाव या प्रभाव है कि मैं अपने ब्राउज़र आधारित जावास्क्रिप्ट को कैसे लिखूं।
मेरे द्वारा बनाई गई और मेरे बैक-एंड प्रौद्योगिकियों के निर्माण की परियोजनाओं में विविधता के कारण, मैं किसी भी कारण से सिंगल सर्वर साइड टेक्नोलॉजी स्टैक में मैरियनेट को लॉक नहीं कर सकता और न ही करूंगा। मैं बॉयलरप्लेट परियोजना प्रदान नहीं करूंगा। मैं एक माणिक रत्न या एक npm पैकेज प्रदान नहीं करूंगा। मैं चाहता हूं कि लोग यह समझें कि Marionette को एक विशिष्ट बैक-एंड सर्वर की आवश्यकता नहीं है। यह ब्राउज़र आधारित जावास्क्रिप्ट है, और बैक-एंड कोई फर्क नहीं पड़ता।
बेशक, मैं अपनी भाषा और ढांचे के लिए पैकेज प्रदान करने वाले अन्य लोगों का पूरा समर्थन करता हूं। मैं उन पैकेजों को विकी में सूचीबद्ध करता हूं और आशा करता हूं कि लोग अधिक पैकेजों का निर्माण जारी रखेंगे क्योंकि वे एक जरूरत देखते हैं। लेकिन वह सामुदायिक समर्थन है, मैरियनेट से प्रत्यक्ष समर्थन नहीं।
आसानी से चूक को बदलें
बॉयलरप्लेट कोड को कम करने और समझदार चूक प्रदान करने के मेरे प्रयास में (जो कि एक विचार है कि मैं सीधे टिम ब्रैनेन के लेआउटमैनगर से "उधार") लेता हूं, मैं अन्य डेवलपर्स की ज़रूरत को थोड़ा अलग कार्यान्वयन का उपयोग करने के लिए पहचानता हूं।
मैं <script>टेम्पलेट के लिए इनलाइन टैग के आधार पर रेंडरिंग प्रदान करता हूं , डिफ़ॉल्ट रूप से टेंपरेचरिंग का उपयोग करके। लेकिन आप इसे Marionette में Renderer/ और TempalteCacheवस्तुओं को बदलकर बदल सकते हैं । ये दो वस्तुएं प्रतिपादन क्षमताओं का मूल प्रदान करती हैं, और विकी पृष्ठ हैं जो दिखाते हैं कि इसे विशिष्ट टेंपलेटिंग इंजन और लोड करने के विभिन्न तरीकों के लिए कैसे बदलना है।
Marionette के v0.9 के साथ, यह और भी आसान हो जाता है। उदाहरण के लिए, यदि आप इनलाइन टेम्प्लेट स्क्रिप्ट ब्लॉक के उपयोग को पूर्व संकलित टेम्प्लेट से बदलना चाहते हैं, तो आपको केवल रेंडरर पर एक विधि को बदलना होगा:
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
और अब पूरा अनुप्रयोग पूर्व-संकलित टेम्पलेट्स का उपयोग करेगा जो आप अपने दृश्य की templateविशेषता के साथ संलग्न करते हैं ।
मैं v0.9 के साथ एक Marionette.Async ऐड-ऑन भी प्रदान करता हूं जो आपको अतुल्यकालिक रूप से प्रस्तुत करने वाले विचारों का समर्थन करने की अनुमति देता है। मैं मैरियनट में डिफ़ॉल्ट व्यवहारों को बदलने के लिए इसे यथासंभव आसान बनाने के लिए निरंतर प्रयास करता हूं।
कॉन्फ़िगरेशन के रूप में कोड
मैं कुछ संदर्भों में "कॉन्फ़िगरेशन पर कन्वेंशन" का प्रशंसक हूं। यह चीजों को प्राप्त करने का एक शक्तिशाली तरीका है, और मैरियोनेट इसे थोड़ा सा प्रदान करता है - हालांकि बहुत अधिक नहीं, ईमानदारी से। कई अन्य ढांचे - विशेष रूप से लेआउटमैन - मैरियनेट की तुलना में कॉन्फ़िगरेशन पर अधिक सम्मेलन प्रदान करते हैं।
यह उद्देश्य और इरादे के साथ किया जाता है।
मैंने एक सार्थक और तेज़ तरीके से काम करने के लिए सम्मेलनों की कोशिश करने के दर्द को जानने के लिए पर्याप्त जावास्क्रिप्ट प्लगइन्स, चौखटे, ऐड-ऑन और एप्लिकेशन बनाए हैं। यह गति के साथ किया जा सकता है, लेकिन आमतौर पर इसे बदलने में सक्षम होने की कीमत पर।
उस अंत तक, मैं मैरियनट के लिए एक "कोड के रूप में कॉन्फ़िगरेशन" दृष्टिकोण लेता हूं। मैं बहुत सारे "कॉन्फ़िगरेशन" एपीआई प्रदान नहीं करता हूं जहां आप स्थैतिक मूल्यों के साथ एक वस्तु शाब्दिक प्रदान कर सकते हैं जो व्यवहारों की एक अदला-बदली को बदलते हैं। इसके बजाय, मैं उन विधियों का दस्तावेजीकरण करता हूं जिनमें प्रत्येक वस्तु है - दोनों एनोटेट स्रोत कोड के माध्यम से और वास्तविक एपीआई प्रलेखन के माध्यम से - आपको यह बताने के इरादे से कि आप कैसे चाहते हैं काम करने के लिए मैरियनट को बदल सकते हैं।
मैरियनट वस्तुओं के लिए एक साफ और स्पष्ट एपीआई प्रदान करके, मैं एक ऐसी स्थिति बनाता हूं जहां एक विशिष्ट वस्तु या मैरियनेट के व्यवहार को पूरी तरह से सरल और बहुत ही लचीला बनाया जाता है। मैं "सरल" कॉन्फ़िगरेशन एपीआई का त्याग करता हूं ताकि आप जो चाहते हैं, उस तरह से काम करने के लिए अपना कोड प्रदान करने के लचीलेपन के लिए कॉल कर सकें।
आपको Marionette में "कॉन्फ़िगर" या "विकल्प" API नहीं मिलेगा। लेकिन आपको बड़ी संख्या में ऐसे तरीके मिलेंगे, जिनमें से प्रत्येक स्वच्छ हस्ताक्षर के साथ एक बहुत ही विशिष्ट उद्देश्य की पूर्ति करता है, जिससे यह बदलना आसान हो जाता है कि मार्वेट कैसे काम करता है।
