मॉड्यूल बाध्यकारी Node.js में दृष्टिकोण का विश्लेषण

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

• कठिन निर्भरताएं (आवश्यकता) ()
• निर्भरता इंजेक्शन
• सेवा लोकेटर
• एंबेडेड डिपेंडेंसी कंटेनर (DI कंटेनर)

मॉड्यूल के बारे में थोड़ा सा

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

कठिन व्यसनों

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

// ourModule.js const db = require('db'); //    ... 

पेशेवरों:

• आराम
• मॉड्यूल का दृश्य संगठन
• आसान डिबगिंग

विपक्ष:

• मॉड्यूल के पुन: उपयोग के लिए कठिनाई (उदाहरण के लिए, यदि हम अपने मॉड्यूल का बार-बार उपयोग करना चाहते हैं, लेकिन डेटाबेस के एक अलग उदाहरण के साथ)
• इकाई परीक्षण के लिए कठिनाई (आपको एक डमी डेटाबेस उदाहरण बनाना होगा और किसी तरह इसे मॉड्यूल को पास करना होगा)

सारांश:

दृष्टिकोण छोटे अनुप्रयोगों या प्रोटोटाइप के साथ-साथ स्टेटलेस मॉड्यूल को जोड़ने के लिए अच्छा है: कारखाने, डिजाइनर और फीचर सेट।

निर्भरता इंजेक्शन

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

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

 // ourModule.js module.exports = (db) => { //       ... }; 

बाहरी मॉड्यूल:

 const dbFactory = require('db'); const OurModule = require('./ourModule.js'); const dbInstance = dbFactory.createInstance('instance1'); const ourModule = OurModule(dbInstance); 

अब हम न केवल अपने मॉड्यूल का पुन: उपयोग कर सकते हैं, बल्कि इसके लिए आसानी से एक इकाई परीक्षण भी लिख सकते हैं: बस डेटाबेस उदाहरण के लिए एक नकली वस्तु बनाएं और इसे मॉड्यूल को पास करें।

पेशेवरों:

• यूनिट टेस्ट लिखने में आसानी
• मॉड्यूल की पुन: प्रयोज्यता बढ़ाएं
• व्यस्तता कम हुई, कनेक्टिविटी बढ़ी
• एक उच्च स्तर पर निर्भरता बनाने के लिए जिम्मेदारी स्थानांतरण - अक्सर यह कार्यक्रम की पठनीयता में सुधार करता है, क्योंकि महत्वपूर्ण निर्भरताएं एक ही स्थान पर एकत्र की जाती हैं, और मॉड्यूल द्वारा नहीं फैलती हैं

विपक्ष:

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

सारांश:

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

सेवा लोकेटर

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

 // serviceLocator.js const dependencies = {}; const factories = {}; const serviceLocator = {}; serviceLocator.register = (name, instance) => { //[2] dependencies[name] = instance; }; serviceLocator.factory = (name, factory) => { //[1] factories[name] = factory; }; serviceLocator.get = (name) => { //[3] if(!dependencies[name]) { const factory = factories[name]; dependencies[name] = factory && factory(serviceLocator); if(!dependencies[name]) { throw new Error('Cannot find module: ' + name); } } return dependencies[name]; }; 

बाहरी मॉड्यूल:

 const serviceLocator = require('./serviceLocator.js')(); serviceLocator.register('someParameter', 'someValue'); serviceLocator.factory('db', require('db')); serviceLocator.factory('ourModule', require('ourModule')); const ourModule = serviceLocator.get('ourModule'); 

हमारा मॉड्यूल:

 // ourModule.js module.exports = (serviceLocator) => { const db = serviceLocator.get('db'); const someValue = serviceLocator.get('someParameter'); const ourModule = {}; //  ,   ... return ourModule; }; 

यह ध्यान दिया जाना चाहिए कि सेवा लोकेटर इंस्टेंस के बजाय सेवा कारखानों को संग्रहीत करता है, और यह समझ में आता है। हमें आलसी आरंभीकरण के लाभ मिले हैं, और अब हमें मॉड्यूल के आरंभीकरण क्रम के बारे में चिंता करने की ज़रूरत नहीं है - जब आवश्यक हो तो सभी मॉड्यूल को आरंभीकृत किया जाएगा। साथ ही, हमें सेवा लोकेटर ("someParameter" देखें) में पैरामीटर स्टोर करने का अवसर मिला।

पेशेवरों:

• यूनिट टेस्ट लिखने में आसानी
• मॉड्यूल का पुन: उपयोग एक कठिन लत के मुकाबले आसान है
• हार्ड एडिक्शन की तुलना में जुड़ाव कम, कनेक्टिविटी बढ़ी
• उच्च स्तर पर निर्भरता बनाने के लिए जिम्मेदारी स्थानांतरण
• मॉड्यूल आरंभीकरण आदेश का पालन करने की आवश्यकता नहीं है

विपक्ष:

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

सारांश

सामान्य तौर पर, एक सेवा लोकेटर निर्भरता इंजेक्शन के समान है, कुछ मायनों में यह आसान है (कोई प्रारंभ क्रम नहीं है), कुछ चीजों में यह अधिक कठिन है (पुन: उपयोग कोड की संभावना से कम)।

एंबेडेड डिपेंडेंसी कंटेनर (DI कंटेनर)

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

 const fnArgs = require('parse-fn-args'); module.exports = function() { const dependencies = {}; const factories = {}; const diContainer = {}; diContainer.factory = (name, factory) => { factories[name] = factory; }; diContainer.register = (name, dep) => { dependencies[name] = dep; }; diContainer.get = (name) => { if(!dependencies[name]) { const factory = factories[name]; dependencies[name] = factory && diContainer.inject(factory); if(!dependencies[name]) { throw new Error('Cannot find module: ' + name); } } diContainer.inject = (factory) => { const args = fnArgs(factory) .map(dependency => diContainer.get(dependency)); return factory.apply(null, args); } return dependencies[name]; }; 

सेवा लोकेटर की तुलना में, इंजेक्शन विधि जोड़ा गया है, जो इसकी आवृत्ति बनाने से पहले मॉड्यूल की निर्भरता निर्धारित करता है। बाहरी मॉड्यूल कोड बहुत अधिक नहीं बदला है:

 const diContainer = require('./diContainer.js')(); diContainer.register('someParameter', 'someValue'); diContainer.factory('db', require('db')); diContainer.factory('ourModule', require('ourModule')); const ourModule = diContainer.get('ourModule'); 

हमारा मॉड्यूल एक साधारण निर्भरता इंजेक्शन के साथ बिल्कुल वैसा ही दिखता है:

 // ourModule.js module.exports = (db) => { //       ... }; 

अब हमारे मॉड्यूल को डीआई कंटेनर की सहायता से और एक साधारण निर्भरता इंजेक्शन का उपयोग करके, सीधे आवश्यक निर्भरता उदाहरणों को पारित करने के लिए कहा जा सकता है।

पेशेवरों:

• यूनिट टेस्ट लिखने में आसानी
• मॉड्यूल का आसान पुन: उपयोग
• सगाई कम, मॉड्यूल की वृद्धि हुई कनेक्टिविटी (विशेषकर सेवा लोकेटर की तुलना में)
• एक उच्च स्तर पर निर्भरता बनाने के लिए जिम्मेदारी स्थानांतरण
• मॉड्यूल इनिशियलाइज़ेशन पर नज़र रखने की आवश्यकता नहीं है

सबसे बड़ा ऋण:

• मॉड्यूल बाध्यकारी तर्क की महत्वपूर्ण जटिलता

सारांश

इस दृष्टिकोण को समझना अधिक कठिन है और इसमें थोड़ा अधिक कोड शामिल है, लेकिन यह अपनी शक्ति और लालित्य के कारण इस पर खर्च किए गए समय के लायक है। छोटी परियोजनाओं में, यह दृष्टिकोण निरर्थक हो सकता है, लेकिन विचार किया जाना चाहिए कि क्या एक बड़े आवेदन को डिजाइन किया जा रहा है।

निष्कर्ष

Node.js. में मॉड्यूल बाइंडिंग के लिए बुनियादी दृष्टिकोण पर विचार किया गया। जैसा कि आमतौर पर होता है, "सिल्वर बुलेट" मौजूद नहीं है, लेकिन डेवलपर को संभावित विकल्पों के बारे में पता होना चाहिए और प्रत्येक विशिष्ट मामले के लिए सबसे उपयुक्त समाधान चुनना चाहिए।

लेख 2017 में जारी Node.js डिज़ाइन पैटर्न किताब के एक अध्याय पर आधारित है। दुर्भाग्य से, पुस्तक में कई चीजें पहले से ही पुरानी हैं, इसलिए मैं इसे पढ़ने की सिफारिश नहीं कर सकता, लेकिन कुछ चीजें आज भी प्रासंगिक हैं।