एक्सटेंशन/प्लगइन संचार के लिए आर्किटेक्चर

Question

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

मेरा प्रश्न इस विस्तार बिंदुओं से निपटने के तरीके के बारे में है। मुझे लगता है कि ऐसा करने का अलग अलग तरीकों से देखा है, लेकिन मैं पेशेवरों और हर एक के विपक्ष के बारे में सुनिश्चित नहीं कर रहा हूँ और अगर वहाँ अधिक और बेहतर तरीके यह पूरा करने के हैं:

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

क्या आपने कभी भी उजागर दृष्टिकोण में से एक उपयोगकर्ता को देखा है? किसने आपके लिए सबसे अच्छा काम किया?

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

Answer 1

आपके डिजाइन निर्णय के लिए एक कुंजी का विश्लेषण करना और एक स्पष्ट तस्वीर प्राप्त करना है कि प्लगइन एक-दूसरे से कितने अलग होंगे।

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

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

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

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

आम तौर पर मैं कहूंगा कि प्रोटोकॉल शुरुआत से ही सही ढंग से डिजाइन करना सबसे कठिन है, क्योंकि आपके पास ठोस या विशिष्ट आप लाइन को आकर्षित करने के लिए ठोस महसूस नहीं कर सकते हैं।

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

Answer 2

मैं पर्यवेक्षक पैटर्न के साथ जाऊंगा। GOF से:

एक एक-से-कई निर्भरता वस्तुओं के बीच परिभाषित करें ताकि एक वस्तु परिवर्तन राज्य जब अपने सभी आश्रितों अधिसूचित और स्वचालित रूप से अपडेट किया जाता है।

प्रकाशित-सदस्यता के रूप में भी जाना जाता है, मैं सुझाव दूंगा कि यह आपके उदाहरणों में दो मामले से सबसे करीबी मिलान करेगा।