डीजेगो, रेल रूटिंग ... प्वाइंट?

Question

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

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

"द रेल्स वे" पुस्तक जिसे मैं पढ़ रहा हूं, यह स्वीकार करता है कि यह कुत्ता धीमा है और यह बड़े पैमाने पर परियोजनाओं पर सबसे अधिक प्रदर्शन दर्द का कारण है। मेरा सवाल है "यह पहली जगह क्यों है?"? क्या url-maps-to-a-file paradigm (या एक फ़ाइल में mod_rewrite) में कोई विशिष्ट बिंदु है जो regexes और जटिल रूटिंग योजनाओं की आवश्यकता है? क्या मैं उन्हें इस्तेमाल नहीं कर रहा हूं?

अग्रिम धन्यवाद!

Answer 1

• यूआरएल याद रखना और कहना आसान होना चाहिए। और उपयोगकर्ता को पता होना चाहिए कि वह यूआरएल कब देखेगी। फ़ाइल को सीधे मैपिंग यूआरएल हमेशा इसकी अनुमति नहीं देता है।
• आप इसके लिए अलग-अलग URL का उपयोग करना चाहेंगे, या कम से कम समान जानकारी प्रदर्शित की जा सकती है। यदि आपका सर्वर आपको 1 यूआरएल < -> 1 फ़ाइल मैपिंग का उपयोग करने के लिए मजबूर करता है, तो आपको अन्य फाइलों पर रीडायरेक्ट करने के लिए अपने सभी फ़ंक्शन के साथ अतिरिक्त फ़ाइलें बनाने की आवश्यकता है। या आप mod_rewrite जैसी सामग्री का उपयोग करते हैं जो रेल के यूआरएल मैपिंग को आसान नहीं है।
• मेरी अनुप्रयोगों में से एक में मैं यूआरएल है कि http://www.example.com/उपयोगकर्ता नाम/कुछ अतिरिक्त सामान/ तरह लग रहा है का उपयोग करें। इसे mod_rewrite के साथ भी बनाया जा सकता है, लेकिन कम से कम मेरे लिए django प्रोजेक्ट में urls को कॉन्फ़िगर करना आसान है, फिर प्रत्येक अपाचे उदाहरण में मैं एप्लिकेशन चलाता हूं।

सिर्फ मेरी 2 सेंट ...

Answer 2

इसके अलावा, राउटर mod_rewrite की तरह हैं, लेकिन बहुत अधिक लचीला। वे नियमित अभिव्यक्ति-बाध्य नहीं होते हैं, और इस प्रकार, विभिन्न प्रकार के मार्गों के लिए अधिक विकल्प होते हैं।

Answer 3

इस पर निर्भर करता है कि आपका आवेदन कितना बड़ा है। हमारे पास काफी बड़ा ऐप (50+ मॉडल) है और यह हमें कोई समस्या नहीं पहुंचा रहा है। जब ऐसा होता है, तो हम इसके बारे में चिंता करेंगे।

Answer 4

Django यूआरएल भी बहुत अनुकूलन योग्य हैं। कोड इग्निटर जैसे PHP ढांचे के साथ (मुझे रेल के बारे में निश्चित नहीं है) आपके/वर्ग/विधि/अतिरिक्त/यूआरएल संरचना में मजबूर होना चाहिए। हालांकि यह छोटी परियोजनाओं और ऐप्स के लिए अच्छा हो सकता है, जैसे ही आप कोशिश करते हैं और इसे अधिक गतिशील बनाते हैं, आप समस्याओं में भाग लेते हैं और इसे संभालने के लिए कुछ फ्रेमवर्क कोड को फिर से लिखना पड़ता है।

Answer 5

वेब सर्वर के दस्तावेज़ पेड़ में एप्लिकेशन कोड संग्रहीत करना एक सुरक्षा चिंता है।

• किसी संरूपण गलती से आगंतुकों के लिए स्रोत कोड प्रकट कर सकती है एक सुरक्षा भेद्यता के माध्यम से इंजेक्शन
• फ़ाइल्स HTTP द्वारा तुरंत निष्पादन योग्य हैं अनुरोध करता
• बैकअप फ़ाइलों (उदा बनायापाठ संपादक द्वारा) कोड पता चलता है या गलत कॉन्फ़िगरेशन के मामले में निष्पादन योग्य हो
• पुरानी फ़ाइलों जो व्यवस्थापक को हटा में नाकाम रही है अनायास ही कार्यक्षमता प्रकट कर सकते हैं पुस्तकालय फ़ाइलों को
• अनुरोधों को स्पष्ट रूप से इनकार किया जाना चाहिए
• यूआरएल कार्यान्वयन विवरण प्रकट हो सकता है (जो भाषा/ढांचे का उपयोग किया गया था)

ध्यान दें कि उपरोक्त सभी समस्या तब तक कोई समस्या नहीं है जब तक अन्य चीजें गलत न हों (और इनमें से कुछ गलतियों को भी गंभीर होगा)। लेकिन कुछ हमेशा गलत हो जाता है, और रक्षा की अतिरिक्त रेखाएं अच्छी होती हैं।

Answer 6

इसमें से अधिकांश पहले ही कवर हो चुके हैं, लेकिन किसी ने अभी तक एसईओ का उल्लेख नहीं किया है। Google यूआरएल पर बहुत वजन डालता है, अगर वह यूआरएल widgets.com/browse.php?17 है, तो यह बहुत ही एसईओ अनुकूल नहीं है। यदि आपका यूआरएल widgets.com/products/buttons/ है जो बटन के लिए आपके पेज रैंक पर सकारात्मक प्रभाव डालेगा