फ्रंट कंट्रोलर पैटर्न का उपयोग करने के फायदे और नुकसान क्या हैं?

Question

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

फ्रंट कंट्रोलर का उपयोग करने के फायदे और नुकसान क्या हैं? क्या पैटर्न केवल ढांचे और सीएमएस में उपयोग किया जाता है क्योंकि यह ज्ञात नहीं है कि अंतिम सिस्टम में कौन से पृष्ठ मौजूद होंगे?

Answer 1

श्रीकांत एक अच्छा जवाब है। हालांकि, मैं विकल्प पर विस्तृत करना चाहता हूं। मान लीजिए आप इस सरल यूआरएल पदानुक्रम है:

 
/gallery 
/blog 
/admin/login 
/admin/newpost 

इस (उदाहरण के लिए, पीएचपी) पृष्ठ नियंत्रकों के साथ लागू किया जाता है, तो दोनों gallery.php और blog.php शुरुआत (या आसपास) पर कुछ common.php शामिल करने के लिए की आवश्यकता होगी। हालांकि, login.php और newpost.php दोनों में admin-common.php शामिल हो सकता है, जो स्वयं 'common.php' में खींचता है और '/ admin /' - विशिष्ट सेटअप करता है, जैसे उपयोगकर्ता सत्यापित करना प्रमाणित है।

सामान्यतः, यदि आपके पास URL का पदानुक्रम है, तो यह ऑब्जेक्ट विरासत पेड़ की तरह दिखता है। भाषा-स्तरीय विरासत का उपयोग करने के बजाय, आप जो भी foo-common.php शामिल हैं, उसके पर्यावरण को विरासत में ले रहे हैं।

मैं कल्पना नहीं कर सकता कि फ्रंट कंट्रोलर टेस्टेबिलिटी कैसे बढ़ा रहा है, अंत में, कार्यान्वित किए बिना स्वचालित HTTP उपयोगकर्ता-एजेंट से सटीक समान परीक्षण आवश्यक हैं।

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

Answer 2

फ्रंट कंट्रोलर का उपयोग करने का एक लाभ इसकी टेस्टेबिलिटी है। यदि आप टीडीडी का उपयोग करते हैं तो विभिन्न वेबसाइटों के अनुरोध के मुकाबले नियंत्रक का परीक्षण करना बहुत आसान है।

बाद में जोड़ा गया: टॉम: थिया कारण मेरा मतलब है कि यह अधिक परीक्षण योग्य है क्योंकि आप सामान्य रूप से वेब पृष्ठों को सर्वर पृष्ठों के बजाय कक्षा के रूप में लागू करते हैं। और फिर आप कक्षाओं पर सीधे tetst के बहुत कुछ कर सकते हैं। एक वाक्य में

- आप इसका इस्तेमाल दोहराव से बचने के लिए:

Answer 3

Wikipedia article on Front Controller अलग ढंग से व्यक्त।

एक छोटी सी अधिक विस्तृत:

मोर्चा नियंत्रक "। अनुरोधों को संभालने के लिए एक केंद्रीकृत प्रवेश बिंदु प्रदान करता है" आइए मान लें कि आपके वेब-एप के लिए फ्रंट कंट्रोलर index.php है।

यह स्क्रिप्ट, index.php, पूरे कार्य या सामान्य रूप से सत्र हैंडलिंग, कैशिंग, इनपुट फ़िल्टरिंग जैसे सभी कार्यों को आम तौर पर संभाल लेगा। दिए गए इनपुट के आधार पर यह विशेष कार्य को संभालने के लिए आगे की वस्तुओं और कॉल विधियों को तुरंत चालू करेगा।

फ्रंट कंट्रोलर का विकल्प login.php और order.php जैसी व्यक्तिगत स्क्रिप्ट होगी जिसमें प्रत्येक कोड या ऑब्जेक्ट्स शामिल होंगे जो सभी कार्यों के लिए आम हैं। इसे प्रत्येक स्क्रिप्ट में समावेशन कोड की पुनरावृत्ति की आवश्यकता होगी लेकिन एक स्क्रिप्ट की विशिष्ट आवश्यकताओं के लिए और भी अधिक जगह छोड़ सकती है।

Answer 4

ये कारण हैं कि मैं कभी भी फ्रंट कंट्रोलर का उपयोग नहीं करूंगा।

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

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