गतिशील विधानसभा संकल्प/प्रबंधन

Question

लघु संस्करण

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

---

विस्तार

पृष्ठभूमि

मैं कंपनी मैं वर्तमान में सी # में के लिए काम कर रहा हूँ के लिए आंतरिक उपयोग के लिए बिजनेस प्रोसेस ऑटोमेशन सिस्टम का एक प्रकार विकसित किया है 4. यह बनाता है को परिभाषित करने के लिए 'प्लग-इन' का संपूर्ण उपयोग (कार्य की इकाइयों की परिभाषा में किए जाने वाले कार्यों से) और गतिशील कॉन्फ़िगरेशन मॉडल पर भारी निर्भर करता है जो बदले में सी # 4/नौकरियों को पूरा करने के लिए डीएलआर गतिशील वस्तुओं। इसकी गतिशील प्रकृति के कारण निष्पादन करते समय यह थोड़ा भारी होता है लेकिन यह लगातार काम करता है और हमारी आवश्यकताओं के लिए पर्याप्त प्रदर्शन करता है।

इसमें एक WinForms कॉन्फ़िगरेशन UI शामिल है जो प्लग-इन के कॉन्फ़िगर करने योग्य गुण/फ़ील्ड्स को निर्धारित करने के लिए प्रतिबिंब का व्यापक रूप से उपयोग करता है, साथ ही साथ गुण/फ़ील्ड जो कार्य की प्रत्येक इकाई को संसाधित करने के लिए परिभाषित करता है। यूआई को बीपीए इंजन के शीर्ष पर भी बनाया गया है, इसलिए इसकी जगह (ढीला) ऑब्जेक्ट मॉडल की पूरी तरह से समझ है जो इंजन को अपनी नौकरी करने की इजाजत देता है, जो संयोग से, कई उपयोगकर्ता अनुभव सुधारों को जन्म देता है, जैसे कि , उपयोगकर्ता इनपुट के विज्ञापन-कार्य निष्पादन और कॉन्फ़िगर-टाइम सत्यापन। फिर सुधार के लिए जगह है, हालांकि, ऐसा लगता है कि यह अपना काम करता है।

कॉन्फ़िगरेशन UI निर्दिष्ट सेटिंग्स को क्रमबद्ध/deserialize करने के लिए DataContractSerializer का उपयोग करता है, इसलिए कॉन्फ़िगरेशन द्वारा संदर्भित किसी भी प्लग-इन को कॉन्फ़िगरेशन लोड से पहले (या उस समय) लोड किया जाना चाहिए।

संरचना

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

समस्या

क्योंकि आवेदन में इस्तेमाल किया तानाना मॉडल की

, वहाँ हमेशा एक आवश्यकता है कि config यूआई सेवा आवेदन के रूप में (एक ही पीसी पर) एक ही निर्देशिका से चलाया जाता है किया गया है। इस तरह यूआई हमेशा उन सभी असेंबली के बारे में जानता है जिन्हें सेवा के बारे में पता है, इसलिए उन्हें गायब असेंबली में भाग दिए बिना deserialized किया जा सकता है।अब जब हम सिस्टम से बाहर निकलने के करीब आ रहे हैं, तो हमारे नेटवर्क में किसी भी पीसी पर कॉन्फ़िगरेशन UI को दूरस्थ रूप से अनुमति देने की मांग सुरक्षा उद्देश्यों के लिए हमारे नेटवर्क व्यवस्थापक से आ गई है। आम तौर पर यह एक समस्या नहीं होगी यदि हमेशा तैनात करने के लिए असेंबली का ज्ञात सेट होता है, हालांकि, उपयोगकर्ता निर्मित असेंबली का उपयोग करके एप्लिकेशन का विस्तार करने की क्षमता के साथ, उन असेंबली को हल करने का एक तरीका होना चाहिए जिससे प्लग-इन तत्काल/इस्तेमाल किया जा सकता है।

प्रस्तावित (संभावित स्पष्ट) समाधान

सेवा आवेदन करने के लिए एक WCF सेवा जोड़े विन्यास जो सेवा की है कि उदाहरण के बारे में पता है के खिलाफ ठेठ CRUD संचालन अनुमति देने के लिए और अधिक कार्य करने के लिए विन्यास यूआई rework एक कनेक्ट/डिस्कनेक्ट मॉडल के साथ एसएसएमएस की तरह। यह वास्तव में समस्या को हल नहीं करता है, इसलिए हमें सेवा अनुप्रयोग से किसी प्रकार की सेवा नियंत्रण का खुलासा करने की आवश्यकता होगी ताकि उन असेंबली की पूछताछ की अनुमति मिल सके जो इसके बारे में जानते हैं/जिनके पास पहुंच है। यह ठीक और काफी सीधे आगे है हालांकि सवाल उठता है, "यूआई को उन विधानसभाओं के बारे में कब पता होना चाहिए जिन्हें सेवा के बारे में पता है?" कनेक्ट पर हम सभी असेंबली को सेवा से यूआई में भेज सकते हैं ताकि यह सुनिश्चित किया जा सके कि यह हमेशा सेवा के सभी असेंबली के बारे में जानता है लेकिन यह ऐपडोमेन प्रबंधन (संभावित रूप से अनावश्यक रूप से) और असेंबली संस्करण संघर्षों के साथ गन्दा हो जाता है। तो मैंने ऐपडोमेन में हुकिंग का सुझाव दिया। एस्प्लोरर रीसोलव/ऐपडोमेन। टाइप केवल उन असेंबली को डाउनलोड करने के लिए करें जिन्हें क्लाइंट अभी तक और केवल आवश्यकतानुसार नहीं जानता है। यह ऐपडोमेन प्रबंधन मुद्दों को जरूरी नहीं है लेकिन यह निश्चित रूप से संस्करण विवादों और संबंधित मुद्दों को हल करने में मदद करता है।

प्रश्न

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

मुझे पता है कि हर कोई मेरे सिर में नहीं रहता है, इसलिए अगर आपको और स्पष्टीकरण/स्पष्टीकरण की आवश्यकता है तो कृपया मुझे बताएं। धन्यवाद!

अद्यतन

मैं MEF एक निष्पक्ष शेक दिया जाता है और लगता है कि यह मेरी प्रयोजनों के लिए बहुत साधारण है है। ऐसा नहीं है कि यह मेरे आवेदन की प्लग-इन आवश्यकताओं को संभालने के लिए तैयार नहीं हो सकता है, समस्या यह कर रही है ताकि इसे व्यवहार्य बनाने के लिए बहुत बोझिल और गंदा हो। यह एक अच्छा सुझाव है और इसमें बहुत सी संभावनाएं हैं, लेकिन वर्तमान स्थिति में यह अभी तक नहीं है।

मेरे प्रस्तावित समाधानों पर कोई अन्य विचार या प्रतिक्रिया?

अद्यतन

अगर मैं ठीक से वर्णन करने के लिए मैं क्या हासिल करने की कोशिश कर रहा हूँ में विफल रहा है मैं, यदि समस्या मैं का सामना कर रहा हूँ अभी भी स्थानीय है पता नहीं है, या अगर यह सवाल अभी भी अनुचित रूप से लंबा है पूरी तरह से पढ़ने के लिए; लेकिन मुझे प्राप्त कुछ उत्तरों काफी मददगार हैं जो मुझे समस्या के माध्यम से अलग-अलग सोचने में मदद करने के लिए पर्याप्त हैं और मैं जो कुछ भी कर रहा हूं उसमें कुछ कमियों की पहचान करता हूं।

संक्षेप में, मैं जो करने की कोशिश कर रहा हूं वह तीन अनुप्रयोगों को लेता है जो एक सामान्य निर्देशिका संरचना का उपयोग कर अपने वर्तमान राज्य साझा जानकारी (कॉन्फ़िगरेशन/असेंबली) में हैं, और उन अनुप्रयोगों को नेटवर्क पर कम से कम प्रभाव के साथ काम करने का प्रयास करें प्रयोज्यता और वास्तुकला।

फ़ाइल शेयरों जब कुछ गलत हो जाता है उन्हें नियंत्रण और debugability की कमी में तब्दील हो का उपयोग कर इस समस्या का स्पष्ट जवाब की तरह लग (@SimonMourier टिप्पणी में प्रस्तावित), लेकिन। मैं उन्हें एक व्यवहार्य अल्पकालिक समाधान के रूप में देख सकता हूं, लेकिन दीर्घकालिक वे केवल व्यवहार्य प्रतीत नहीं होते हैं।

Answer 1

tl; डॉ, लेकिन मुझे 9 0% यकीन है कि आपको MEF पर एक नज़र रखना चाहिए।
जब मैंने पहली बार देखा तो मैं "आह, एक और संक्षिप्त शब्द" जैसा था, लेकिन आप देखेंगे कि यह बहुत आसान है, और इसे .NET 4 में बनाया गया है। सबसे अच्छा, यह मोनो पर भी निर्बाध रूप से चलता है और यह एक बात है इसके बारे में सुनने और सुविधाओं के साथ उपयोग करने के लिए हैलो दुनिया को संकलित करने के बीच एक घंटे से भी कम (कॉफी ब्रेक सहित)। यह वास्तव में इतना आसान है।

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

संपादित करें: यदि आप कॉन्फ़िगरेशन लोड पर ऑन-द-फ्लाई डाउनलोड और लोड (और संभावित रूप से कैश) प्लगइन करने का प्रयास करते हैं तो क्या होगा?

Answer 2

शायद तुम दो

1. व्यवस्थापक में इस समस्या को विभाजित कर सकते हैं (पुस्तकालयों का सेट) उन पूर्वनिर्धारित विन्यास में से एक डाउनलोड करने की अनुमति और MEF उपयोगकर्ता के प्रत्येक गतिविधि के माध्यम से पारित करना चाहिए आवश्यक निर्भरता

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

   [MyRole (नाम = नई [] { "Security.Action"})] शून्य BlockAccount (स्ट्रिंग ACCOUNTID) {}

   [MyRole (नाम = नई [] { "Manager.Action" })] शून्य createaccount (स्ट्रिंग उपयोगकर्ता नाम) {}

   [MyRole (नाम = नई [] { "Security.View", "Manager.View"})] सूची <> AcountList (विधेय पी) {}

और एफ को अनुमति दें या विज्ञापन समूह (कुछ सार वर्णन)

1. कॉर्प \ securityOperators = "सुरक्षा। *" // // सभी सुरक्षा हेरफेर
2. कॉर्प \ HQmanager = "Manager.View" करने के लिए कॉल की अनुमति केवल देखने की एक्सेस
अनुमति देते हैं
3. कॉर्प \ ऑपरेटर = "प्रबंधक *।"

Answer 3

मुझे लगता है कि आप एक अपेक्षाकृत सरल समाधान है कि माइक्रोसॉफ्ट web.config दृष्टिकोण से कुछ हद तक निकला अनदेखी की जा सकती है:

दो से है कॉन्फ़िगरेशन फ़ाइल में ctions:

अनुभाग 1 में प्लगइन के बारे में पर्याप्त जानकारी है (यानी। नाम, संस्करण) आपको इसे एक ऐप डोमेन में लोड करने की अनुमति देता है।

अनुभाग 2 में प्लगइन द्वारा क्रमबद्ध जानकारी शामिल है।

प्लगइन लोड करने पर, अनुभाग 2 में जानकारी पास करें और प्लगइन को इसकी आवश्यकताओं के अनुसार इसे deserialize दें।

Answer 4

मुझे यकीन नहीं है कि मैं पूरी तरह से समस्या को समझता हूं लेकिन मुझे लगता है कि यह स्थिति "प्रकार-संरक्षित क्रमबद्धता" के लिए कहती है - यानी, धारावाहिक फ़ाइल में मूल ऑब्जेक्ट ग्राफ़ पर किसी भी संकेत के बिना deserialize करने के लिए पर्याप्त प्रकार की जानकारी होती है कॉलिंग एप्लिकेशन से किस प्रकार शामिल हैं।

मैंने ऐसा करने के लिए Json.NET का उपयोग किया है और मैं ऑब्जेक्ट ग्राफ़ के प्रकार-संरक्षित क्रमबद्धता के लिए लाइब्रेरी की अत्यधिक अनुशंसा कर सकता हूं। ऐसा लगता है कि NetDataContractSerializer भी से the MSDN Remarks

NetDataContractSerializer एक महत्वपूर्ण तरीका में DataContractSerializer से अलग है यह कर सकते हैं,: NetDataContractSerializer धारावाहिक एक्सएमएल में CLR प्रकार की जानकारी भी शामिल है, जबकि DataContractSerializer नहीं करता है। इसलिए, NetDataContractSerializer का उपयोग तभी किया जा सकता है जब दोनों धारावाहिक और deserializing समाप्त होता है एक ही सीएलआर प्रकार साझा करते हैं।

मैंने जेसन.NET चुना क्योंकि यह किसी विशेष विशेषताओं या इंटरफेस के बिना पीओसीओ को क्रमबद्ध कर सकता है। Json.NET और NetDataContractSerializer दोनों आपको कस्टम SerializationBinder का उपयोग करने की अनुमति देते हैं - यहां आप असेंबली लोड करने के संबंध में कोई तर्क डाल सकते हैं जो अभी तक लोड नहीं हो सकता है।

दुर्भाग्य से, क्रमबद्ध क्रमिक योजनाएं "ब्रेकिंग-एस्ट" परिवर्तन हो सकती हैं ताकि सुझाव दिया जा सके क्योंकि आपकी सभी मौजूदा फाइलें असंगत हो जाएंगी। आप एक रूपांतरण उपयोगिता लिखने में सक्षम हो सकते हैं जो पुरानी विधि का उपयोग कर फ़ाइल को deserializes और नई विधि का उपयोग कर परिणामस्वरूप ऑब्जेक्ट ग्राफ serializes।