2009-03-02 10 views
24

यह प्रश्न Rasmus Lerdorf's talk from Drupalcon देखने से उपजी है। इस सवाल और उनकी बात के पास विशेष रूप से ड्रूपल के साथ कुछ भी नहीं है, वैसे ... यह सिर्फ उनके कंस में दिया गया था। मेरे अपने प्रश्न में PHP के साथ कुछ भी विशिष्ट नहीं है। यह सामान्य रूप से एकल प्रविष्टि बिंदु है कि मैं उत्सुक हूं।वेबसाइट पर एक एकल प्रविष्टि बिंदु होने के बाद। खराब? अच्छा? गैर मुद्दा?

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

उत्तर

29

संक्षेप में, Rasmus या व्याख्या गलत है।

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

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

+0

भाई पर सही। कोई तर्क दे सकता है कि एक वेब सर्वर एक एकल प्रविष्टि बिंदु है। रasmस क्या प्रस्तावित करता है वह DRY नहीं है, क्योंकि सभी स्क्रिप्ट को अलग-अलग संसाधनों को व्यक्तिगत रूप से लोड करना होगा। फ्रंट कंट्रोलर इसका ख्याल रखता है। – rick

+0

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

4

महत्वपूर्ण बात यह है कि आप एक वेब ढांचे का उपयोग करते हैं जो लोड-बैलेंसिंग और घोषणात्मक कोड जैसे तरीकों के माध्यम से स्केलेबिलिटी का समर्थन करता है।

नहीं, एक एकल प्रविष्टि बिंदु स्वयं में बाधा उत्पन्न नहीं करता है। Google के सामने वाले पृष्ठ को बहुत सारी हिट मिलती हैं, लेकिन उनके पास बहुत से सर्वर हैं।

तो जवाब है: इससे कोई फर्क नहीं पड़ता।

1

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

मुझे लगता है कि यह अजीब है हालांकि। मैं इस समय एक छोटा एमवीसी फ्रेमवर्क स्वयं बना रहा हूं लेकिन यह मेरे द्वारा उपयोग किए जाने वाले अधिकांश ढांचे के विपरीत है। मैं अभिगम फ़ाइल में नियंत्रक तर्क डाल दिया। उदाहरण के लिए, index.php में इंडेक्स कंट्रोलर और उसके क्रियाएं होंगी। यह दृष्टिकोण कम से कम मेरे लिए अच्छा काम कर रहा है।

2

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

1

चूंकि अधिकांश PHP एमवीसी ढांचे कुछ प्रकार के यूआरएल पुनर्लेखन का उपयोग करते हैं, या कम से कम index.php के बाद कुछ भी पार्स करते हैं, तो एक एकल प्रविष्टि बिंदु आवश्यक है।

कि इसके अलावा, मैं संदर्भ प्रति प्रवेश द्वारों प्रदान करना चाहते, कहते हैं कि वेब (/ साबुन)/कंसोल/...

4

सॉफ्टवेयर विकास में कुछ भी पसंद है, यह निर्भर करता है। फ्रंट-कंट्रोलर स्टाइल फ्रेमवर्क के लिए रasmस की आपत्ति यह है कि आप प्रत्येक अनुरोध पर इतने सारे कोड अप-फ्रंट लोड करने से प्रदर्शन प्रदर्शन करते हैं। यह 100% सच है। यहां तक ​​कि यदि आप किसी प्रकार के स्मार्ट-संसाधन लोडिंग मॉड्यूल/ऑब्जेक्ट/आदि का उपयोग कर रहे हैं, तो फ्रेमवर्क का उपयोग करना एक प्रदर्शन व्यापार-बंद है। आप प्रदर्शन हिट नहीं ले सकता है, लेकिन बदले में आपको वापस

  1. "व्यापार तर्क" (जो कि है) और खाका/लेआउट तर्क प्रोत्साहित जुदाई

  2. त्वरित और (अधिक महत्वपूर्ण) एकीकृत मिल Rasmus की तरह एक पुरुष के लिए वस्तुओं आप डेटाबेस प्रश्नों के लिए इस्तेमाल करेंगे करने के लिए उपयोग, सेवा कहा जाता है, अपने डेटा मॉडल, आदि

, इस प्रदर्शन हिट के लायक नहीं है। वह एक सी/सी ++ प्रोग्रामर है। उनके लिए, यदि आप अत्यधिक तर्कसंगत तरीके से व्यावसायिक तर्क को अलग करना चाहते हैं, तो आप PHP में सी/सी ++ एक्सटेंशन लिखते हैं।

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

यदि यह आपका पर्यावरण नहीं है, तो उत्पादकता बढ़ने पर विचार करें कि फ्रंट-कंट्रोलर फ्रेमवर्क आपके (likely) simple CRUD Application पर ला सकता है।

1

बस जोड़ने के लिए, आम तौर पर लोग जो सोचते हैं वह यह है कि, क्योंकि एक PHP पृष्ठ है, यह एक ही पृष्ठ है जो सभी अनुरोधों की सेवा करता है। कतार की तरह क्रमबद्ध करें।

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

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

व्यक्तिगत रूप से, मैं बहु पृष्ठ पसंद करता हूं, वैसे ही मैं ओओपी और प्रक्रियात्मक मिश्रण करता हूं। मुझे पुराना स्कूल रास्ता php पसंद है।

0

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

सैम बहस कर रहा है कि एक फ्रंट-कंट्रोलर आपको कई स्थानों पर कोड संपादित करने से बचा सकता है, लेकिन मुझे लगता है कि कुछ मामलों में, यह अनावश्यकता को अलग करके बेहतर हल किया जाता है।

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

2

मुझे लगता है कि यह "एक फ़ाइल" बनाम "कई फाइलों" के बिंदु से इस पर चर्चा करने में एक बड़ी गलतफहमी है।

कोई यह सोचने लगता है कि प्रविष्टि बिंदु एक फ़ाइल में है, तो हमें उस पर ध्यान देना होगा कि वह एक फ़ाइल में कोड है - यह गलत है।

सभी लोकप्रिय ढांचे में प्रवेश के लिए प्रवेश मैनिपुलेशन कोड, व्याख्या कोड और सत्यापन कोड के साथ कई फाइलें हैं। यह कोड एक ही स्थान पर स्थित नहीं है, बल्कि अनुरोध किए जाने वाले अनुरोधों के आधार पर अलग-अलग वर्गों को बुलाए जाने वाले जंगल में चारों ओर फैला हुआ है।

दोनों मामलों में अनुरोध वास्तव में विभिन्न फ़ाइलों द्वारा संभाला जाता है।

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

URI.php में CodeIgniters _detect_uri() फ़ंक्शन पर नज़र डालें। कोडइग्निटर पर नहीं चुनना, यह सिर्फ एक उदाहरण है। अन्य ढांचे इसी तरह से करता है।

आप एक प्रवेश बिंदु के साथ-साथ कई प्रविष्टि बिंदुओं के साथ एक एमवीसी पैटर्न के लक्ष्यों को प्राप्त कर सकते हैं।

संबंधित मुद्दे