क्या घटक वास्तुकला के लिए भविष्य है?

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

घटक - बिल्डिंग ब्लॉक्स अनुप्रयोग

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

पुन: उपयोग करने वाले घटक

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

ब्राउज़र एक प्रकार का मध्यस्थ है जो प्राप्तकर्ताओं की सूची संग्रहीत करता है। जब घटक के अंदर कोई घटना घटती है, तो उसे इस सूची के सभी प्राप्तकर्ताओं को भेज दिया जाता है।

मध्यस्थ के लिए धन्यवाद, घटक अपने प्राप्तकर्ताओं के बारे में नहीं जानता है। और प्राप्तकर्ता एक निश्चित प्रकार के विभिन्न घटकों से घटनाओं की सदस्यता ले सकते हैं।

घटकों का उपयोग करना उन्हें बनाने की तुलना में आसान है।

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

यह किस कीमत पर हासिल किया गया है? ऐसा करने के लिए, आपको यह निर्धारित करने की आवश्यकता है कि घटक क्या बाहरी घटनाओं को उत्पन्न करेगा और संदेश भेजने वाले तंत्र का उपयोग करने में सक्षम होगा।

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

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

समस्या इस तथ्य से जटिल है कि घटकों के उपयोगकर्ता अक्सर अपने घटक तत्वों के लिए नई घटनाओं को परिभाषित और भेजना नहीं जानते हैं। लेकिन एक ही समय में, वे आसानी से घटक ढांचे में परिभाषित तैयार घटनाओं का उपयोग कर सकते हैं। यानी वे जानते हैं कि घटनाओं को कैसे प्राप्त किया जाए, न कि उन्हें कैसे बनाया जाए और कैसे भेजा जाए।

इस समस्या को हल करने के लिए, आइए देखें कि एप्लिकेशन में ईवेंट मॉडल के उपयोग को कैसे सरल बनाया जाए।

बहुत सारे इवेंट श्रोताओं

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



यह आवेदन में कक्षाओं की संख्या में वृद्धि की ओर जाता है। जो बदले में, सिस्टम के समर्थन और विकास को जटिल बनाता है।

उदाहरण के लिए, जावा में, एनोटेशन से पहले चीजों की यह स्थिति थी। एनोटेशन के साथ, विशिष्ट घटनाओं के तरीकों पर हस्ताक्षर करना संभव हो गया है। एक उदाहरण सीडी ईई 6 से सीडीआई ( कॉन्टेक्ट्स एंड डिपेंडेंसी इंजेक्शन ) में इवेंट मॉडल का कार्यान्वयन है।

public class PaymentHandler { public void creditPayment(@Observes @Credit PaymentEvent event) { ... } } public class PaymentBean { @Inject @Credit Event<PaymentEvent> creditEvent; public String pay() { PaymentEvent creditPayload = new PaymentEvent(); // populate payload ... creditEvent.fire(creditPayload); } } 

और अमरूद पुस्तकालयों में इवेंट बस का कार्यान्वयन:

 // Class is typically registered by the container. class EventBusChangeRecorder { @Subscribe public void recordCustomerChange(ChangeEvent e) { recordChange(e.getChange()); } } // somewhere during initialization eventBus.register(new EventBusChangeRecorder()); // much later public void changeCustomer() { ChangeEvent event = getChangeEvent(); eventBus.post(event); } 

नतीजतन, आपके घटकों के लिए कई ईवेंट श्रोताओं को लागू करने की आवश्यकता नहीं है। एप्लिकेशन में घटनाओं का उपयोग करना बहुत आसान हो गया है।

इवेंट बस का उपयोग करना सुविधाजनक है जब एप्लिकेशन घटकों को एक साथ स्क्रीन पर रखा जाता है और इसके माध्यम से संदेशों का आदान-प्रदान किया जाता है, जैसा कि नीचे दिए गए चित्र में दिखाया गया है।



शीर्षक, बाईं ओर मेनू, मध्य में सामग्री, दाईं ओर पैनल, ये सभी तत्व ईवेंटबस का उपयोग करके स्वचालित रूप से पुन: प्रयोज्य घटकों में परिवर्तित हो जाते हैं। क्योंकि वे सीधे एक दूसरे पर निर्भर नहीं होते हैं, लेकिन संचार के लिए एक सामान्य बस का उपयोग करते हैं।

घटनाओं की सदस्यता - सदस्यता समाप्त करने के लिए मत भूलना!

ईवेंट श्रोताओं को एनोटेशन के साथ बदलना - ईवेंट मॉडल के उपयोग को सरल बनाने के लिए एक बड़ा कदम उठाया गया था।
हालांकि, इवेंट बस से घटक प्राप्त करने के लिए घटक के लिए, इसे पंजीकृत होना चाहिए। और ताकि वह घटनाओं को प्राप्त करना बंद कर दे, फिर उसे प्राप्तकर्ताओं की सूची से हटा दें। इन जिम्मेदारियों को किसे लेना चाहिए?



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

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



कॉन्फ़िगरेशन द्वारा निर्देशित नियंत्रक, सिस्टम बस की वर्तमान स्थिति के आधार पर, इवेंट बस में घटनाओं के लिए संबंधित स्क्रीन पर हस्ताक्षर करता है।

Finite State Machines को सिर्फ इसी मकसद से बनाया गया था। उनके पास ऐसे राज्य भी हैं जिनके भीतर घटनाएं घटती हैं। और ऐसी घटनाएं जो राज्यों के बीच संक्रमण को ट्रिगर करती हैं।

आवेदन राज्यों को कॉन्फ़िगर करने के लिए परिमित राज्य मशीनों का उपयोग करने के लाभ।

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



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



इसके अलावा, सिस्टम के सभी घटक ईवेंट भेजने के लिए एक एकीकृत तंत्र का उपयोग करके संवाद कर सकते हैं - नियंत्रक (स्टेटमैचिन) के माध्यम से।

यह दृष्टिकोण अनुप्रयोग के सभी घटकों (रूपों, खिड़कियों, पैनलों) को पुन: प्रयोज्य घटकों में बदल देता है जिन्हें बाहरी कॉन्फ़िगरेशन का उपयोग करके आसानी से नियंत्रित किया जा सकता है।

आवेदन को कॉन्फ़िगर करने के लिए प्रभावी ढंग से स्टेटमैचिन का उपयोग कैसे करें यह अगले लेख में वर्णित किया जाएगा।

PS यदि आप रुचि रखते हैं, तो आप एंटरप्राइज़ सैम्पलर में कॉन्फ़िगरेशन के उदाहरण देख सकते हैं

यह जानना दिलचस्प होगा कि आप अनुप्रयोगों के निर्माण में घटक वास्तुकला के भविष्य और इसकी भूमिका को कैसे देखते हैं।

पीपीएस एक नया लेख जारी किया गया है जिसमें बताया गया है कि इस समाधान का उपयोग कैसे करें: नेविगेशन: कॉर्पोरेट एप्लिकेशन के लिए कार्यान्वयन विकल्प