एक नया नियंत्रक उदाहरण तत्काल करने का ओवरहेड महत्वहीन है, और इसका मतलब है कि दो पूरी तरह से असंबंधित अनुरोधों के बीच कोई गलती से साझा स्थिति नहीं है। प्रोसेसर समय में कोई भी "बचत" विनाशकारी बग का उत्पादन करने की क्षमता से ऑफसेट से अधिक होगी।
याद रखें कि नियंत्रक अनुरोध-विशिष्ट स्थिति संग्रहीत करने के लिए हैं। पुन: उपयोग करने वाले नियंत्रकों को आपको प्रत्येक क्रिया की शुरुआत में, प्रत्येक @variable को रीसेट करने की आवश्यकता होगी। अन्यथा, @is_admin = true जैसे कुछ को सेट अप किया जा सकता है और कभी भी साफ़ नहीं किया जा सकता है। कम विकसित हुई बग जो आप वास्तव में पेश करेंगे, डेवलपर समय पर अधिक सूक्ष्म और draining होगी।
आप अनुकूलन देख रहे हैं जहां कोई भी नहीं है। कुछ को राज्य को बनाए रखना चाहिए और अनुरोधों के बीच इसे रीसेट करना होगा, या आपके पास गलती से साझा राज्य का यह दुःस्वप्न है। यदि आप अनुरोधों के बीच नियंत्रक उदाहरण जारी रखते हैं, तो आप बस कुछ निचले स्तर पर राज्य को बनाए रखने/रीसेट करने की नौकरी को दबा रहे हैं, जहां उत्तर प्रत्येक अनुरोध के लिए कुछ राज्य-प्रबंधन वर्ग के ताजा उदाहरण को तुरंत चालू करने के लिए होगा। कंप्यूटर संसाधनों को आवंटित करने और मुक्त करने पर बहुत अच्छे हैं, इसलिए कभी भी इस बारे में चिंता न करें जब तक आपको वास्तव में यह पता न हो कि यह एक बाधा है। इस मामले में, प्रत्येक अनुरोध के लिए एक नया नियंत्रक तुरंत चालू करना सही विकल्प है।
रेल के मामले में, @variable = value का उपयोग करने में सक्षम होने के कारण कोड-स्पष्टता और उपयोगिता स्टैंड-पॉइंट से एक बड़ी जीत है, और अनुरोध पूरा होने पर नियंत्रक के प्रत्येक उदाहरण को छोड़ने के लिए यह कम या कम आवश्यकता होती है।
अच्छा सवाल है, आपको इसके बारे में डीएचएच से पूछना चाहिए :) लेकिन मुझे लगता है कि मुख्य बिंदु बिल्कुल एक पर्यावरण को अलग करना है। क्योंकि अन्यथा सिस्टम को वितरण तर्क के लिए अधिक प्रसंस्करण शक्ति खर्च करना पड़ता है। imho –
क्योंकि कोड के बारे में तर्क करना आसान है जब किसी अन्य अनुरोध के डेटा पर स्टॉम्पिंग का कोई जोखिम नहीं है। –
कोई आश्चर्य नहीं, लेकिन ऐसा लगता है कि Grails एक ही काम करता है। –