🕴️ ⚒️ ⤴️ हम .Net फ्रेमवर्क पर एक मॉड्यूलर एप्लिकेशन लिखते हैं 🖖🏼 🙎🏿 🌮

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

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

मॉड्यूलर आवेदन डिजाइन कदम

एक मॉड्यूलर अनुप्रयोग विकसित करने के लिए, सबसे पहले, कार्यक्षमता को उजागर करना आवश्यक है जिसे मॉड्यूल की मदद से विस्तारित किया जाना चाहिए।

इसके अलावा, इंटरफेस विकसित किए जाते हैं जिनकी मदद से सिस्टम इस कार्यक्षमता के लिए तीसरे पक्ष के कार्यान्वयन तक पहुंच बनाएगा।

सबसे पतला बिंदु यह है कि इंटरफ़ेस कार्यान्वयन को गतिशील रूप से कैसे जोड़ा जाए।

प्रतिबिंब

.Net फ्रेमवर्क में शक्तिशाली परावर्तन तकनीक है। प्रतिबिंब एक प्रोग्राम को रनटाइम पर अपनी संरचना और व्यवहार को ट्रैक करने और संशोधित करने की अनुमति देता है।

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

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

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

मॉड्यूल संरचना

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

डिवाइस मॉड्यूल का सबसे सरल समाधान निम्नलिखित हो सकता है:

1. मॉड्यूल सभी आवश्यक पुस्तकालयों का एक संग्रह है। संपीड़न एल्गोरिथ्म ज़िप हो सकता है। इसके अलावा, जैसे कि, संपीड़न की आवश्यकता नहीं है (बाइनरी लाइब्रेरीज़ को संग्रह करना मुश्किल है), आपको बस एक फ़ाइल में मॉड्यूल के सभी घटकों को संयोजित करने की आवश्यकता है।

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

प्लगइन डिस्क्रिप्टर को लागू करने के लिए XML का उपयोग करना सुविधाजनक लगता है।

इस तरह के दस्तावेज़ की सबसे सरल संरचना निम्नानुसार हो सकती है:

<?xml version="1.0"?> <plugin> <type> </type> <name> </name> <description> .</description> <version>  </version> <class>   ,    </class> <assembly> </assembly> <dependences> <dependence> </dependence> </dependences> </plugin>

मॉड्यूल को जोड़ना और निकालना

सिस्टम में एक नया मॉड्यूल जोड़ना निम्नलिखित अनुक्रम में हो सकता है:

1. सिस्टम को जोड़े गए मॉड्यूल के साथ फ़ाइल का पूरा पथ स्थानांतरित किया जाता है।
2. इसके विवरणक के अनुपालन के लिए जोड़ा गया मॉड्यूल की जाँच की जाती है: सभी संकेतित पुस्तकालयों की उपस्थिति, मुख्य वर्ग की उपस्थिति और निर्दिष्ट इंटरफ़ेस के कार्यान्वयन की जाँच की जाती है।
3. मॉड्यूल के भंडारण के लिए आरक्षित प्रणाली की निर्देशिका में, जोड़ा मॉड्यूल के लिए एक नया उपनिर्देशिका बनाया गया है। सभी मॉड्यूल पुस्तकालयों को इस निर्देशिका में कॉपी किया जाता है।
4. मॉड्यूल की विशिष्ट पहचानकर्ता * की गणना की जाती है (एक विकल्प के रूप में, आप मॉड्यूल संस्करण की ओर से एक हैश ले सकते हैं)।
5. मॉड्यूल डिस्क्रिप्टर और गणना किए गए पहचानकर्ता से सभी जानकारी मॉड्यूल के सिस्टम रजिस्ट्री में दर्ज की जाती है (एक्सएमएल-फाइल जो सिस्टम में स्थापित मॉड्यूल के बारे में जानकारी संग्रहीत करता है)।
________________________________________
* इस पहचानकर्ता को सिस्टम में काम के अंतिम सत्र में मॉड्यूल के उपयोग के बारे में जानकारी को बचाने की आवश्यकता होती है।

सबसे सरल मामले में, मॉड्यूल रजिस्ट्री एक एक्सएमएल फ़ाइल हो सकती है जिसमें ऊपर की संरचना एक समान होती है, केवल इस अंतर के साथ कि इसमें मॉड्यूल के बारे में कई प्रविष्टियां होंगी:

 <?xml version="1.0"?> <plugins> <plugin> <id>534523</id> <type> </type> <name>  1</name> <description>  1</description> <version>   1</version> <class>   ,    </class> <assembly> </assembly> <dependences> <dependence> </dependence> </dependences> </plugin> <plugin>> <id>79568</id> <type> </type> <name>  2</name> <description>  2</description> <version>   2</version> <class>   ,    </class> <assembly> </assembly> <dependences> <dependence> </dependence> </dependences> </plugin> . . . . </plugins>

मॉड्यूल हटाने के लिए क्रियाओं का क्रम:
1. मॉड्यूल निर्देशिका को हटाने **।
2. रजिस्ट्री से मॉड्यूल के बारे में जानकारी निकालना।

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

वर्ग संरचना

PluginDescriptor - मॉड्यूल के बारे में जानकारी प्रदान करता है जो इसे तुरंत भेजने के लिए पर्याप्त है।

PluginRegister - मॉड्यूल की रजिस्ट्री में संचालन पढ़ता और लिखता है। निर्दिष्ट पहचानकर्ता के अनुरूप मॉड्यूल को एक हैंडल लौटाता है। सभी उपलब्ध मॉड्यूल के लिए विवरणकर्ताओं की पूरी सूची वापस कर सकते हैं।

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

PluginManager - सिस्टम में मॉड्यूल जोड़ता या हटाता है। यह मॉड्यूल की अखंडता पर नजर रखता है जब इसे जोड़ा जाता है। मॉड्यूल प्राप्त करने के तरीकों को एकजुट करने के लिए, "कुंवारा" टेम्पलेट के अनुसार लागू किया गया।

PluginLoader - एक मॉड्यूल को इंस्टेंट करता है । इस वर्ग को पेश करने की आवश्यकता स्वयं इंस्टेंटेशन प्रक्रिया की बारीकियों के कारण होती है, जिसे नीचे चर्चा की जाएगी ( यह लेख भी पढ़ा जा सकता है)।

.Net फ्रेमवर्क के लिए विशिष्ट मॉड्यूल के गतिशील कनेक्शन की मात्रा

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

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

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

स्पष्टता के लिए, मैं PluginLoader वर्ग का कोड दूंगा और Plugin वर्ग के कोड का हिस्सा (उपरोक्त कोड लोड किए गए मॉड्यूल की निर्भरता की उपस्थिति को ध्यान में नहीं रखता है):

 public class BasePlugin { ... /// <summary> ///    . /// </summary> /// <remarks> ///      . /// </remarks> public Object Instance { get { if (instance == null) { instance = LoadInstance(); } return instance; } } /// <summary> ///       ///     . /// </summary> /// <returns> ///     ,  null. /// </returns> private Object LoadInstance() { Descriptor d = this.Descriptor; /*   */ AppDomainSetup setup = new AppDomainSetup(); setup.ShadowCopyFiles = "true"; //    //TODO:      /*     */ AppDomain domain = AppDomain.CreateDomain(d.ToString(), null, setup); /*    */ PluginLoader loader = (PluginLoader)domain.CreateInstanceFromAndUnwrap( typeof(PluginLoader).Assembly.Location, typeof(PluginLoader).FullName); /*    */ Object obj = null; try { obj = loader.CreateInstance(d, PluginManager .GetPluginDirectory(this)); } catch (Exception e) { AppDomain.Unload(domain); throw new PluginLoadException(d, "", e); } return obj; } }

 [Serializable] public class PluginLoader { /// <summary> ///       . /// </summary> /// <param name="d">  .</param> /// <param name="pluginDirectory"> ///      . /// </param> /// <returns> ///  ,   . /// </returns> public Object CreateInstance(Descriptor d, String pluginDirectory) { String assemblyFile = Path.Combine(pluginDirectory, d.AssemblyName); /*   . */ Assembly assembly = null; try { AssemblyName asname = AssemblyName.GetAssemblyName(assemblyFile); assembly = AppDomain.CurrentDomain.Load(asname); } catch (Exception e) { throw new AssemblyLoadException(assemblyFile, "  .", e); } /*    ,  . */ Object obj = null; try { obj = assembly.CreateInstance(d.ClassName); } catch (Exception e) { throw new ClassLoadException(d.ClassName, assembly.FullName, "    .", e); } return obj; } }

निष्कर्ष

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

स्पष्ट रूप से अनसुलझी समस्याओं से, मैं निम्नलिखित का हवाला दे सकता हूं: यदि मॉड्यूल निर्भरता में एक ही पुस्तकालय है, तो अत्यधिक संसाधन खपत संभव है। यदि आपके पास इस मुद्दे पर दिलचस्प विचार हैं - तो इसे साझा करें।

हम .Net फ्रेमवर्क पर एक मॉड्यूलर एप्लिकेशन लिखते हैं