मैं इसे थोड़ी देर के लिए सोच रहा था और वास्तव में इसके लिए अभी तक कोई जवाब नहीं मिला है।रेल और बैकबोन पर रूबी का मिश्रण
रेलवे एप्लिकेशन के अंदर आप Backbone.js exaclty का उपयोग क्यों करेंगे? क्या यह कार्यक्षमता बढ़ाने के लिए है, अपने जेएस के लिए एक और एमवीसी पैटर्न है, बेहतर एपीआई का निर्माण ...?
पल मैं एक कारण है कि आप कुछ करने के लिए इसका उपयोग करना चाहते हैं नहीं देख सकते हैं क्योंकि मुझे नहीं लगता कि मैं Backbone.js की अवधारणा को समझने पर
रेल का बड़ा लाभ यह है कि आप है एक मंच और एक भाषा है जिसका आप उपयोग करते हैं जो सर्वर-कोड को संभालेगा और क्लाइंट-कोड उत्पन्न कर सकता है (दृश्यों का उपयोग करके)।
निस्संदेह यह सैद्धांतिक लाभ जल्दी ही फिसलना शुरू हो जाता है जब आप जावास्क्रिप्ट और jquery के साथ अपने उपयोगकर्ता अनुभव को बेहतर बनाना चाहते हैं। तो वास्तव में आपको अभी भी दो भाषाओं को सीखना है।
लेकिन फिर भी: आपके सभी मॉडल, व्यवसाय-नियम, ... रूबी में सर्वर-साइड पर संभाला जाता है। इसका यह भी अर्थ है कि सर्वर हमेशा पहुंच योग्य होना चाहिए।
क्या एक javacript/क्लाइंट एमवीसी (बैकबोन.जेएस, स्प्राउटकोर, ...) की पेशकश कर सकते हैं आप एक अधिक देशी आवेदन महसूस कर सकते हैं। एक एकल वेब पेज एप्लिकेशन, जैसे उदा। जीमेल लगीं। आपकी आवश्यकताओं के आधार पर ऐसे मंच के लिए कुछ बहुत ही वैध उपयोग-मामले हैं। जैसे कम कनेक्टिविटी वाले स्थानों या उपकरणों में यह बहुत उपयोगी हो सकता है (HTML5 के साथ) एक वेब-एप्लिकेशन है जिसे हर समय "ऑनलाइन" होने की आवश्यकता नहीं होती है। यह स्थानीय स्टोरेज में डेटा और संपादन को सहेज सकता है और डिवाइस वापस ऑनलाइन होने पर सर्वर/डेटाबेस पर वापस सिंक कर सकता है।
लेकिन, रेल के साथ संयोजन में क्लाइंट एमवीसी अनुप्रयोगों को विकसित करते समय एक बड़ा नुकसान होता है: आपको कुछ डबल विकास करना होगा (यह वही है जब आप फ्लेक्स/चांदी की रोशनी का उपयोग कर रहे हों)। आपके मॉडल को सर्वर और क्लाइंट दोनों पर परिभाषित करने की आवश्यकता होगी। मैं कल्पना कर सकता हूं कि क्लाइंट एमवीसी की तरह कुछ सुधार किए जा सकते हैं, आप वास्तव में प्रस्तुति-वर्गों का उपयोग कर रहे हैं, जो सर्वर-साइड पर विभिन्न मॉडलों/तालिकाओं में संग्रहीत किए जा सकते हैं। लेकिन फिर भी तर्क, मॉडल, ...
इसलिए मुझे लगता है कि ज्यादातर अनुप्रयोगों के लिए, कुछ क्लाइंट एमवीसी ढांचे पर स्विच करना बुद्धिमान नहीं है। यह बहुत अधिक काम होगा।
लेकिन जब आपको वास्तविक मूल एप्लिकेशन, या एक पृष्ठ-वेब एप्लिकेशन के स्वरूप और अनुभव की आवश्यकता होती है, तो एक जावास्क्रिप्ट क्लाइंट एमवीसी फ्रेमवर्क जाने का तरीका है। और यदि आपको क्लाइंट एमवीसी ढांचे की आवश्यकता है, तो मैं Sproutcore का प्रस्ताव दूंगा।
अपने वर्तमान रेल एप्लिकेशन को आसानी से अजेज़ करने के लिए (प्रत्येक पृष्ठ के लोड-टाइम को कम करता है), pjax-rails पर एक नज़र डालें।
डुप्लिकेशन से बचने के लिए आपके पास पतला सर्वर हो सकता है। बस डेटा एक्सेस और सत्यापन। – Raynos
हां, लेकिन रेल मॉडलों को बनाने में बहुत आसान बनाता है, सत्यापन जोड़ें, ... बैकबोन/स्प्राउटकोर में आपको मॉडलों को फिर से परिभाषित करना होगा, विशेषताओं को परिभाषित करना होगा, स्थानीय सत्यापन जोड़ें, व्यवसाय तर्क जोड़ें (जो शायद नहीं है सर्वर पर अब आवश्यक है?)। तो अभी भी डुप्लिकेट कोड होगा। इस डुप्लिकेशन को अब टाला नहीं जा सकता है। – nathanvda
गलत शब्द से बचें। डुप्लिकेशंस को कम करने के लिए बैकबोन में रेल पर रहने वाले कुछ कोड को स्थानांतरित करें। हालांकि RoR के फायदे खोने वाले पतले सर्वर (डेटा स्टोरेज और सत्यापन) का उपयोग करना। नकल से बचने का एकमात्र तरीका रेल का उपयोग नहीं करना है। – Raynos
(कभी भी देर से बेहतर नहीं - उम्मीद है कि यह किसी के लिए उपयोगी है) बैकबोनजेस की वेबसाइट पर विवरण बहुत सारे शब्दों के बिना एक साथ फेंक दिया गया लगता है। इसके चारों ओर एक बड़ा प्रचार है लेकिन इसके बारे में क्या झगड़ा है?
रीढ़ की हड्डी के पीछे आधार यह है कि आधुनिक दिन, एकल पृष्ठ वेब ऐप्स (लगता है जीमेल) जल्दी से डोम तत्वों, यूआई घटनाओं और बैकएंड को सिंक करने के बीच एक बहुत ही जटिल बातचीत बन जाता है। आप आसानी से डोम तत्वों के भीतर डेटा संग्रहीत कर सकते हैं, और फिर किसी भी तरह डेटाबेस को अद्यतन करने के लिए डेटा को फिर से निकालने के लिए। यदि आप अपने कोड को बहुत सावधानी से नहीं बनाते हैं, तो आप जल्दी से जटिल बाइंडिंग से भरा स्पेगेटी कोड, या रीढ़ की हड्डी के बिना कोड समाप्त कर देंगे।
रीढ़ की हड्डी के मॉडल, संग्रह और विचारों का उपयोग करके आप काम करने के लिए एक अच्छी तरह से विचार की गई संरचना प्रदान करते हैं, जिससे आप अपनी जटिलता से अभिभूत किए बिना बड़े ऐप्स बनाने की अनुमति देते हैं। और क्या है, यह एक आरामदायक बैकएंड के साथ खूबसूरती से संबंध रखता है।
तो क्या आप कहेंगे कि बैकबोन.जेएस एकल पृष्ठ वेब ऐप्स के उपयोग के मामले के लिए बनाया गया था, जबकि एक पूरी तरह से रेल समाधान अच्छी तरह से काम करता है जहां एक वेब ऐप कई पृष्ठों/स्क्रीन से बना होता है? –
बड़े और बड़े, हां। लेकिन मैं यह भी जोड़ूंगा कि आपका ऐप कई पेजों/स्क्रीनों से बना है, लेकिन उनमें से कुछ जावास्क्रिप्ट के बड़े हिस्से से बने हैं, फिर भी आप अपने कोड को व्यवस्थित करने के लिए रीढ़ की हड्डी का उपयोग करने से लाभ उठा सकते हैं। क्या आप नियंत्रकों या मॉडल का उपयोग किए बिना एक फ़ाइल में रेल बैकएंड लिखेंगे? शायद ऩही। इसी तरह यदि आपका फ्रंटएंड कोड कुछ और जटिल करने के लिए शुरू कर रहा है, तो रीढ़ की हड्डी आपके कोड को संरचित करने में मूल्य जोड़ना शुरू कर देगी। –
http://backbonetutorials.com आपको शुरू करने में मदद कर सकता है। –