जावास्क्रिप्ट में निर्भरता इंजेक्शन का एक और कार्यान्वयन ES6 मॉड्यूल के साथ है, एक ब्राउज़र में और नोड्ज में एक ही कोड का उपयोग करने और ट्रांसपैरर्स का उपयोग न करने की क्षमता के साथ।

कट के तहत डीआई पर मेरा विचार है, आधुनिक वेब अनुप्रयोगों में इसका स्थान, एक डीआई कंटेनर का मौलिक कार्यान्वयन जो आगे और पीछे दोनों तरफ वस्तुओं का निर्माण कर सकता है, साथ ही माइकल जैक्सन को इसके साथ क्या करना है, इसका स्पष्टीकरण भी।

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

आवेदन में वस्तुओं

मैं वास्तव में कार्यात्मक प्रोग्रामिंग का सम्मान करता हूं, लेकिन मैंने अपनी अधिकांश व्यावसायिक गतिविधि को वस्तुओं से मिलकर बनाने के लिए समर्पित किया है। जावास्क्रिप्ट मुझे इस तथ्य से प्रभावित करता है कि इसमें कार्य भी ऑब्जेक्ट हैं। एप्लिकेशन बनाते समय, मैं वस्तुओं के बारे में सोचता हूं, यह मेरी पेशेवर विकृति है।

जीवनकाल के अनुसार, आवेदन में वस्तुओं को निम्नलिखित श्रेणियों में विभाजित किया जा सकता है:

• स्थायी - आवेदन के कुछ चरण में उत्पन्न होता है और केवल आवेदन पूरा होने पर नष्ट हो जाता है;
• अस्थायी - तब उत्पन्न होता है जब कुछ ऑपरेशन करना आवश्यक होता है और इस ऑपरेशन के पूरा होने पर नष्ट हो जाते हैं;

इस संबंध में, प्रोग्रामिंग में इस तरह के डिजाइन पैटर्न हैं:

• सिंगलटन ;
• अमूर्त कारखाना , बिल्डर , पूल , ...

यही है, मेरे दृष्टिकोण से, आवेदन में स्थायी रूप से मौजूदा कुंवारे होते हैं जो या तो आवश्यक संचालन स्वयं करते हैं या उन्हें निष्पादित करने के लिए अस्थायी ऑब्जेक्ट उत्पन्न करते हैं।

ऑब्जेक्ट कंटेनर

निर्भरता इंजेक्शन एक दृष्टिकोण है जो किसी एप्लिकेशन में ऑब्जेक्ट बनाना आसान बनाता है। यही है, आवेदन में एक विशेष वस्तु है जो "जानता है" अन्य सभी वस्तुओं को कैसे बनाया जाए। इस तरह के ऑब्जेक्ट को ऑब्जेक्ट कंटेनर (कभी-कभी ऑब्जेक्ट मैनेजर) कहा जाता है।

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

कार्यान्वयन का स्थान

किसी वस्तु में निर्भरता को इंजेक्ट करने के दो तरीके हैं:

• निर्माता के माध्यम से;
• एक संपत्ति (या उसके एक्सेसर) के माध्यम से;

मैंने मूल रूप से पहले दृष्टिकोण का उपयोग किया है, इसलिए मैं कंस्ट्रक्टर के माध्यम से निर्भरता इंजेक्शन के दृष्टिकोण के साथ विवरण जारी रखूंगा।

मान लीजिए कि हमारे पास एक एप्लिकेशन है जिसमें तीन ऑब्जेक्ट हैं:

PHP में (लंबे समय तक चलने वाली DI परंपराओं के साथ यह भाषा, मेरे पास वर्तमान में सक्रिय सामान है, मैं थोड़ी देर बाद JS पर आगे बढ़ूंगा) एक समान स्थिति इस तरह से परिलक्षित हो सकती है:

class Config { public function __construct() { } } class Service { private $config; public function __construct(Config $config) { $this->config = $config; } } class Application { private $config; private $service; public function __construct(Config $config, Service $service) { $this->config = $config; $this->service = $service; } } 

यह जानकारी पर्याप्त होनी चाहिए ताकि एक डीआई कंटेनर (उदाहरण के लिए, लीग / कंटेनर ), यदि उचित रूप से कॉन्फ़िगर किया गया हो, तो Application ऑब्जेक्ट बनाने और उन्हें पैरामीटर को Application ऑब्जेक्ट के निर्माता को पास करने के अनुरोध पर अपनी Service और Config निर्भरता भी बना सकता है।

निर्भरता पहचानने वालों

ऑब्जेक्ट कंटेनर कैसे समझता है कि Application ऑब्जेक्ट के निर्माता को दो Config और Service ऑब्जेक्ट की आवश्यकता है? परावर्तन एपीआई ( जावा , पीएचपी ) के माध्यम से या वस्तु कोड का सीधे विश्लेषण करके (कोड एनोटेशन)। यही है, सामान्य मामले में, हम उन चर के नामों को निर्धारित कर सकते हैं जो ऑब्जेक्ट निर्माता इनपुट पर देखने की अपेक्षा करता है, और यदि भाषा टाइप करने योग्य है, तो हम इन चर के प्रकार भी प्राप्त कर सकते हैं।

इस प्रकार, वस्तुओं के पहचानकर्ता के रूप में, कंटेनर निर्माणकर्ता के इनपुट मापदंडों या इनपुट मापदंडों के प्रकारों के नामों के साथ काम कर सकता है।

ऑब्जेक्ट बनाएँ

ऑब्जेक्ट प्रोग्रामर द्वारा स्पष्ट रूप से बनाया जा सकता है और कंटेनर में संबंधित पहचानकर्ता के तहत रखा जा सकता है (उदाहरण के लिए, "कॉन्फ़िगरेशन")

 /** @var \League\Container\Container $container */ $container->add("configuration", $config); 

और कंटेनर द्वारा कुछ विशिष्ट नियमों के अनुसार बनाया जा सकता है। ये नियम, द्वारा और बड़े, वस्तु के पहचानकर्ता से उसके कोड से मेल खाते हैं। नियम स्पष्ट रूप से सेट किए जा सकते हैं (कोड, XML, JSON, ... के रूप में मैपिंग)

 [ ["object_id_1", "/path/to/source1.php"], ["object_id_2", "/path/to/source2.php"], ... ] 

या कुछ एल्गोरिथ्म के रूप में:

 public function getSource($id) {. return "/path/to/source/${id}.php"; } 

PHP में, अपने सोर्स कोड के साथ एक वर्ग के नाम को एक फ़ाइल से मिलान करने के नियम मानकीकृत हैं ( PSR-4 ), जावा में, मिलान JVM ( क्लास लोडर ) कॉन्फ़िगरेशन स्तर पर किया जाता है। यदि कंटेनर ऑब्जेक्ट बनाते समय स्रोतों के लिए एक स्वचालित खोज प्रदान करता है, तो ऐसे कंटेनर में ऑब्जेक्ट्स के लिए वर्ग नाम अच्छे पर्याप्त पहचानकर्ता हैं।

नेमस्पेस

आमतौर पर एक परियोजना में, अपने स्वयं के कोड के अलावा, तृतीय-पक्ष मॉड्यूल का भी उपयोग किया जाता है। निर्भरता प्रबंधकों (मावेन, संगीतकार, एनपीएम) के आगमन के साथ, मॉड्यूल के उपयोग को बहुत सरल किया गया है, और परियोजनाओं में मॉड्यूल की संख्या बहुत बढ़ गई है। Namespaces एक ही नाम के कोड तत्वों को विभिन्न मॉड्यूल (वर्गों, कार्यों, स्थिरांक) से एकल प्रोजेक्ट में मौजूद होने की अनुमति देता है।

ऐसी भाषाएं हैं जिनमें नाम स्थान शुरू में बनाया गया है (जावा):

 package vendor.project.module.folder; 

ऐसी भाषाएं हैं जिनमें भाषा के विकास के दौरान नाम स्थान जोड़ा गया था (PHP):

 namespace Vendor\Project\Module\Folder; 

एक अच्छा नामस्थान कार्यान्वयन आपको कोड के किसी भी तत्व को स्पष्ट रूप से संबोधित करने की अनुमति देता है:

 \Doctrine\Common\Annotations\Annotation\Attribute::$name 

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

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

 $container->add(\Vendor\Project\Module\ObjectType::class, $obj); 

कोड स्टार्टअप

PHP composer मॉड्यूल नेमस्पेस को composer.json अंदर फ़ाइल सिस्टम में मैप किया जाता है। composer.json मॉड्यूल विवरणक में:

 "autoload": { "psr-4": { "Doctrine\\Common\\Annotations\\": "lib/Doctrine/Common/Annotations" } } 

JS में नाम स्थान होने पर JS समुदाय package.json में समान मैपिंग कर सकता है।

जेएस निर्भरता पहचानकर्ता

ऊपर, मैंने संकेत दिया कि कंटेनर निर्माणकर्ता के इनपुट मापदंडों के नाम या पहचानकर्ता के रूप में इनपुट मापदंडों के प्रकार का उपयोग कर सकता है। समस्या यह है कि:

1. JS डायनामिक टाइपिंग वाली भाषा है और फ़ंक्शन की घोषणा करते समय निर्दिष्ट प्रकारों के लिए प्रदान नहीं करती है।
2. JS मिनिफायर्स का उपयोग करता है जो इनपुट मापदंडों का नाम बदल सकता है।

ओवलिक्स डीआई कंटेनर के डेवलपर्स, निर्माता को केवल इनपुट पैरामीटर के रूप में ऑब्जेक्ट का उपयोग करने का सुझाव देते हैं, और इस ऑब्जेक्ट के गुणों पर निर्भर करता है:

 class UserController { constructor(opts) { this.userService = opts.userService } } 

JS में ऑब्जेक्ट प्रॉपर्टी आइडेंटिफ़ायर में अल्फ़ान्यूमेरिक वर्ण, "_" और "$" शामिल हो सकते हैं, और एक अंक से शुरू नहीं हो सकता है।

चूँकि हमें ऑटोलैड के लिए फ़ाइल सिस्टम में उनके स्रोतों के लिए निर्भरता पहचानकर्ताओं को मैप करने की आवश्यकता होगी, इसलिए "$" का उपयोग छोड़ना और PHP के अनुभव का उपयोग करना बेहतर है। namespace संचालक कुछ चौखटों में दिखाई दिया (उदाहरण के लिए, Zend 1 में), निम्न नाम वर्गों के लिए उपयोग किए गए थे:

 class Zend_Config_Writer_Json {...} 

इस प्रकार, हम जेएस पर तीन वस्तुओं ( Application , Config , Service ) के हमारे आवेदन को कुछ इस तरह दर्शा सकते हैं:

 class Vendor_Project_Config { constructor() { } } class Vendor_Project_Service { constructor({Vendor_Project_Config}) { this.config = Vendor_Project_Config; } } class Vendor_Project_Application { constructor({Vendor_Project_Config, Vendor_Project_Service}) { this.config = Vendor_Project_Config; this.service = Vendor_Project_Service; } } 

यदि हम प्रत्येक वर्ग का कोड पोस्ट करते हैं:

 export default class Vendor_Project_Application { constructor({Vendor_Project_Config, Vendor_Project_Service}) { this.config = Vendor_Project_Config; this.service = Vendor_Project_Service; } } 

हमारे प्रोजेक्ट मॉड्यूल के अंदर आपकी फ़ाइल में:

• ./src/
  
  • ./Application.js
  • ./Config.js
  • ./Service.js

तब हम कन्टेनर के विन्यास में माड्यूल की मूल निर्देशिका को "नेमस्पेस" से जोड़ सकते हैं:

 const ns = "Vendor_Project"; const path = path.join(module_root, "src"); container.addSourceMapping(ns, path); 

और फिर, इस जानकारी से शुरू करके, निर्भरता पहचानकर्ता ( ${module_root}/src/Config.js ) के आधार पर संबंधित स्रोतों ( ${module_root}/src/Config.js ) के लिए पथ का निर्माण करें।

ES6 मॉड्यूल

ES6 ES6 मॉड्यूल लोड करने के लिए एक सामान्य डिजाइन प्रदान करता है :

 import { something } from 'path/to/source/with/something'; 

चूँकि हमें एक ऑब्जेक्ट (क्लास) को एक फाइल में अटैच करने की आवश्यकता है, यह डिफ़ॉल्ट रूप से इस क्लास को एक्सपोर्ट करने के लिए सोर्स में मायने रखता है:

 export default class Vendor_Project_Path_To_Source_With_Something {...} 

सिद्धांत रूप में, कक्षा के लिए इतना लंबा नाम नहीं लिखना संभव है, बस Something काम करेगा, लेकिन Zend 1 में उन्होंने लिखा और नहीं टूटा, और परियोजना के भीतर वर्ग नाम की विशिष्टता आईडीई की दोनों क्षमताओं को सकारात्मक रूप से प्रभावित करती है (स्वतः पूर्ण और प्रासंगिक संकेत), इसलिए और जब डिबगिंग:

एक वर्ग आयात करना और इस मामले में एक वस्तु बनाना इस तरह दिखता है:

 import Something from 'path/to/source/with/something'; const something = new Something(); 

आगे और पीछे का आयात

आयात ब्राउज़र और नोडज दोनों में काम करता है, लेकिन बारीकियां हैं। उदाहरण के लिए, ब्राउज़र नोडज मॉड्यूल के आयात को नहीं समझता है:

 import path from "path"; 

हमें ब्राउज़र में एक त्रुटि मिलती है:

 Failed to resolve module specifier "path". Relative references must start with either "/", "./", or "../". 

यदि हम चाहते हैं कि हमारा कोड ब्राउज़र और नोडज दोनों में काम करे, तो हम उन निर्माणों का उपयोग नहीं कर सकते हैं जो ब्राउज़र या नोडज को समझ में नहीं आते हैं। मैं विशेष रूप से इस पर ध्यान केंद्रित करता हूं, क्योंकि इस तरह के निष्कर्ष के बारे में सोचना स्वाभाविक है। सांस कैसे लें?

आधुनिक वेब अनुप्रयोगों में DI का स्थान

यह मेरे व्यक्तिगत अनुभव के कारण विशुद्ध रूप से मेरी व्यक्तिगत राय है, जैसे इस प्रकाशन में बाकी सब कुछ।

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

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

DI पहले से उपयोग में है, आवश्यकताएँ में:

 define( ["./config", "./service"], function App(Config, Service) {} ); 

सच है, यहां निर्भरता के पहचानकर्ताओं को स्पष्ट रूप से और सूत्रों के लिंक के रूप में तुरंत लिखा जाता है (आप बूटलोडर कॉन्फ़िगरेशन में पहचानकर्ताओं के मानचित्रण को कॉन्फ़िगर कर सकते हैं)।

आधुनिक वेब अनुप्रयोगों में, डीआई न केवल सर्वर साइड पर, बल्कि ब्राउज़र में भी मौजूद है।

माइकल जैक्सन का इससे क्या लेना-देना है?

जब आप ईएस-मॉड्यूल समर्थन को नोडज (फ्लैग --experimental-modules ) में सक्षम करते हैं, तो इंजन एक्मास्क्रिप्ट-मॉड्यूल के रूप में *.mjs साथ फाइलों की सामग्री की पहचान करता है ( *.mjs साथ कॉमन-मॉड्यूल के विपरीत)।

इस दृष्टिकोण को कभी-कभी " माइकल जैक्सन समाधान " कहा जाता है, और लिपियों को माइकल जैक्सन स्क्रिप्स ( *.mjs ) कहा जाता है।

मैं मानता हूं कि केडीपीवी के साथ इतनी साज़िश का समाधान किया गया था, लेकिन ... दोस्तों का कैमोन , माइकल जैक्सन ...

फिर भी एक और DI कार्यान्वयन

खैर, जैसा कि उम्मीद थी, अपना बाइक DI मॉड्यूल - @ teqfw / di

यह तैयार-टू-फाइट समाधान नहीं है, बल्कि एक मौलिक कार्यान्वयन है। सभी निर्भरता ईएस-मॉड्यूल होनी चाहिए और ब्राउज़र और नोडज के लिए सामान्य सुविधाओं का उपयोग करना चाहिए।

निर्भरता को हल करने के लिए, मॉड्यूल ओपिलिक्स दृष्टिकोण का उपयोग करता है:

 constructor(spec) { /** @type {Vendor_Module_Config} */ const _config = spec.Vendor_Module_Config; /** @type {Vendor_Module_Service} */ const _service = spec.Vendor_Module_Service; } 

पिछला उदाहरण चलाने के लिए:

 import Container from "./src/Container.mjs"; const container = new Container(); container.addSourceMapping("Vendor_Module", "../example"); container.get("Vendor_Module_App") .then((app) => { app.run(); }); 

सर्वर पर:

 $ node --experimental-modules main.mjs 

सामने उदाहरण चलाने के लिए ( example.html ):

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>DI in Browser</title> <script type="module" src="./main.mjs"></script> </head> <body> <p>Load main script './main.mjs', create new DI container, then get object by ID from container.</p> <p>Open browser console to see output.</p> </body> </html> 

आपको सर्वर पर मॉड्यूल डालने और ब्राउज़र में example.html पृष्ठ खोलने की आवश्यकता है (या आईडीई का उपयोग करें)। यदि आप example.html सीधे खोलते हैं, तो Chrome में त्रुटि है:

 Access to script at 'file:///home/alex/work/teqfw.di/main.mjs' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https. 

यदि सब कुछ ठीक रहा, तो कंसोल (ब्राउज़र या नोडज) में कुछ इस तरह होगा:

 Create object with ID 'Vendor_Module_App'. Create object with ID 'Vendor_Module_Config'. There is no dependency with id 'Vendor_Module_Config' yet. 'Vendor_Module_Config' instance is created. Create object with ID 'Vendor_Module_Service'. There is no dependency with id 'Vendor_Module_Service' yet. 'Vendor_Module_Service' instance is created (deps: [Vendor_Module_Config]). 'Vendor_Module_App' instance is created (deps: [Vendor_Module_Config, Vendor_Module_Service]). Application 'Vendor_Module_Config' is running. 

सारांश

AMD, CommonJS, UMD?

ESM !