निर्भरता इंजेक्शन बनाम प्रबंधित निर्भरता बनाम वैश्विक वस्तु

Question

मैं जावास्क्रिप्ट + बैकबोनजेएस (एक एमवीसी फ्रेमवर्क) + आवश्यकताजेएस फ्रेमवर्क के भीतर काम कर रहा हूं, लेकिन यह सवाल कुछ हद तक सामान्य है।

मुझे बताया कि रीढ़ में से शुरू करते हैं, अपने विचार पारंपरिक दृश्य और नियंत्रकों का मिश्रण हैं, और अपने HTML टेम्पलेट्स हैं पारंपरिक MVC दृश्य

थोड़ी देर के लिए इस बारे में मेरे सिर रैकिंग गया और मैं कर रहा हूँ सुनिश्चित नहीं है कि सही/व्यावहारिक दृष्टिकोण क्या होना चाहिए।

मेरे पास एक उपयोगकर्ता ऑब्जेक्ट है जिसमें उपयोगकर्ता प्राथमिकताएं (जैसे यूनिट सिस्टम, भाषा चयन, कुछ और) शामिल है जो बहुत से कोड पर निर्भर करता है।

मेरे कुछ दृश्य टेम्पलेट्स के उपयोग के बिना अधिकांश काम करते हैं (तृतीय पक्ष libs का उपयोग करके, मैपिंग और ग्राफ़िंग libs की तरह), और इस तरह वे उपयोगकर्ता ऑब्जेक्ट पर यूनिट रूपांतरण की देखभाल करने के लिए निर्भरता रखते हैं, उदाहरण के लिए। मैं वर्तमान में आवश्यकता को प्रबंधित करने के लिए Requjs का उपयोग कर रहा हूं बिना encapsulation तोड़ने के।

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

मेरा सवाल है, इस तरह की व्यापक रूप से आवश्यक निर्भरता को सर्वोत्तम तरीके से कैसे संभालना है? - एक ऐप-व्यापी संदर्भ/वैश्विक वस्तु बनाएं जो हर जगह सुलभ हो? (YUK) - RequJS प्रबंधित निर्भरताओं का उपयोग करें, भले ही यह आमतौर पर कंक्रीट ऑब्जेक्ट्स की बजाय कक्षा/ऑब्जेक्ट परिभाषाओं के लिए प्रबंधित निर्भरता लोडिंग का उपयोग करने की अनुशंसा की जाती है। - या, केवल निर्भरता इंजेक्शन का उपयोग करें, और मैन्युअल रूप से उस निर्भरता को उस सब कुछ में पारित करें जो इसकी आवश्यकता है?

Answer 1

पूरी तरह से तकनीकी दृष्टिकोण से, मैं तर्क दूंगा कि कम्युनिटी ग्लोबल्स (ग्लोबल्स जो बदल सकते हैं), खासकर जावास्क्रिप्ट में, खतरनाक और गलत हैं। विशेष रूप से जब जावास्क्रिप्ट कोड के उन हिस्सों से भरा होता है जो असीमित रूप से निष्पादित होते हैं। निम्नलिखित कोड पर विचार करें: यदि addSomeStuffToLoggedinUser() एसिंक्रोनस रूप से कहीं न कहीं कार्यान्वित

window.loggedinuser = Users.get("Paul"); 
addSomeStuffToLoggedinUser(); 
window.loggedinuser = Users.get("Sam"); 
doSomeOtherStuffToLoggedinUser(); 

अब (उदाहरण के लिए यह एक ajax कॉल, और फिर एक और ajax कॉल जब पहले एक खत्म करता है), यह बहुत अच्छी तरह से नई loggedInUser से सामान जोड़ने हो सकता है ("सैम"), जब तक यह दूसरी AJAX कॉल तक पहुंच जाता है। स्पष्ट रूप से आप क्या चाहते हैं नहीं।

यह कहकर कि, मैं कुछ उपयोगकर्ता ऑब्जेक्ट रखने के समर्थक से भी कम हूं जिसे हम फ़ंक्शन से फ़ंक्शन, विज्ञापन infinitum से हर समय हाथ में रखते हैं।

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

तो, मुझे लगता है कि यह सब आपके ऐप पर निर्भर करता है। एक बात है कि यह बेहतर बनाता है (और आप आप अभी भी कुछ OO कर्म अंक हो रही है की तरह महसूस करता है) कुछ namespaced सिंगलटन में अपने डेटा को छिपाने के लिए है:

var myuser = MyApp.domain.LoggedinDomain.getLoggedinUser(); 
doSomethingCoolWith(myuser); 

doSomethingCoolWith(window.loggedinuser); 

हालांकि की जगह में

यह अंत में एक ही चीज़ है ...

Answer 2

मुझे लगता है कि आप पहले से ही अपने प्रश्न का उत्तर दे चुके हैं, आप बस किसी और को यह कहना चाहते हैं:) DI का उपयोग करें, लेकिन आप वास्तव में "मैन्युअल रूप से" उस निर्भरता को पारित नहीं कर रहे हैं क्योंकि आपको इसका उपयोग करने के लिए संदर्भित करने की आवश्यकता है वैसे भी।

Answer 3

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