MEF में अपनी खुद की गुंजाइश को परिभाषित करना

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


जैसा कि आप जानते हैं, MEF में केवल दो स्कोप हैं - शेयर्ड (प्रति कंटेनर में एक उदाहरण) और नॉनसेरेड (प्रत्येक निर्यात अनुरोध के लिए एक नया उदाहरण)। यूनिटी के बाद इस कंटेनर का अध्ययन करने वालों के संभवतः पहले प्रश्नों में से एक: "और प्रति धागा दृश्यता कहाँ है?"। या, WCF सेवा डेवलपर्स के लिए, "प्रति-कॉल"।
यह सवाल करने के बिना कि यह रचना कार्यों के हिस्से के रूप में क्यों आवश्यक है, मैं इन दृश्यता नीतियों के सामान्य तरीके से कार्यान्वयन का एक सरल उदाहरण दिखाने की कोशिश करूंगा।

उन लोगों के लिए जो निर्माण और तकनीकी विवरणों के चरणों के बारे में नहीं पढ़ना चाहते हैं, यहां आप अपने हाथों से कोड को छू सकते हैं, और यहां - इसे पैकेज के रूप में उठा सकते हैं।

यह केवल एमईएफ 2.0 में काम करता है, और नीचे - क्यों।

So.
पहले, समस्या को सामान्य तरीके से बताने की कोशिश करते हैं:
“निर्यात अनुरोध में कुछ संदर्भ है। इस अनुरोध के समय, आपको एक ही संदर्भ के लिए समान निर्यात उदाहरण और विभिन्न संदर्भों के लिए अलग-अलग उदाहरण देने की आवश्यकता है। "

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

public abstract class AffinityStorage<TExport, TAffinity> where TExport : class { private ConcurrentDictionary<TAffinity,TExport> _partStorage = new ConcurrentDictionary<TAffinity,TExport>(); internal TExport GetOrAdd(TAffinity affinity, Func<TExport> creator) { var t = _partStorage.GetOrAdd(affinity, (a) =>creator()); return t; } internal void RemoveAffinity(TAffinity affinity) { TExport val; _partStorage.TryRemove(affinity, out val); } } 

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

लेकिन इस कारखाने की विधि कहाँ से प्राप्त करें? याद रखें कि उसे एक पूर्ण भाग वापस करना चाहिए, संभवतः अपने स्वयं के आयात के साथ।
ऐसा करने के लिए, "आलसी" रूप में भाग के एक उदाहरण को वापस करने के लिए MEF क्षमता का लाभ उठाएं। और संदर्भ निर्धारित करने के लिए, और वास्तव में एक आवरण के रूप में, हम एक और वर्ग बनाएंगे - रसीद नीति। वह नॉनशेड के परिप्रेक्ष्य में है, क्योंकि हमारा आलसी निर्यात हर अनुरोध पर नया होना चाहिए (और इसे बनाने के लिए या नहीं, हमारा भंडारण समझ जाएगा)।

  public abstract class Policy<TExport, TAffinity> where TExport : class { private readonly AffinityStorage<TExport, TAffinity> _storage; [Import(AllowRecomposition = true, RequiredCreationPolicy = CreationPolicy.NonShared)] private Lazy<TExport> _lazyPart; private bool _wasCreated; private int _wasDisposed; protected abstract TAffinity GetAffinity(); protected Policy(AffinityStorage<TExport, TAffinity> storage) { _storage = storage; } private TExport GetExportedValue() { _wasCreated = true; return _storage.GetOrAdd(GetAffinity(), () => _lazyPart.Value); } protected void DestroyAffinity(TAffinity affinity) { var wasDisposed = Interlocked.CompareExchange(ref _wasDisposed, 1, 0); if (_wasCreated && wasDisposed == 0) { _storage.RemoveAffinity(affinity); } } public static implicit operator TExport(Policy<TExport, TAffinity> threadPolicy) { return threadPolicy.GetExportedValue(); } } 

यहाँ, जैसा कि हम देखते हैं, वहाँ हैं:

• आलसी <TExport> के रूप में हमारे कारखाने की विधि, आवश्यक रूप से नॉनशेड, अन्यथा इसकी आवश्यकता क्यों है
• हमारी रिपॉजिटरी में निर्यात के माध्यम से किसी नीति को लक्ष्य प्रकार में परिवर्तित करना
• एक सार पद्धति के रूप में, किस संदर्भ की परिभाषा है, जिसे हम वंशजों में लागू करेंगे
• संदर्भ बंधन हटाने विधि

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

हम अंत में इस अंतिम कार्यान्वयन - धारा के लिए करते हैं।

  [Export(typeof(ThreadStorage<>))] [PartCreationPolicy(CreationPolicy.Shared)] internal sealed class ThreadStorage<TExport> : AffinityStorage<TExport, Thread> where T : class { } [Export(typeof (ThreadPolicy<>))] [PartCreationPolicy(CreationPolicy.NonShared)] public sealed class ThreadPolicy<TExport> : Policy<TExport, Thread> where T : class { protected override Thread GetAffinity() { return Thread.CurrentThread; } [ImportingConstructor] internal ThreadPolicy( [Import(RequiredCreationPolicy = CreationPolicy.Shared)] ThreadStorage<TExport> storage) : base(storage) { } } 

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

यह इस तरह से उदाहरण के लिए काम करता है (हमें निश्चित रूप से, हमारे द्वारा बनाए गए सभी चीज़ों को एक कंटेनर में रखना चाहिए):

  TestPart part = _container.GetExportedValue<ThreadPolicy<TestPart>>(); 

या तो:

 [Export] class Outer { Inner _perThreadObject; [ImportingConstructor] Outer([Import]ThreadPolicy <Inner> perThreadObject) { _perThreadObject = perThreadObject; } } 

क्या पर्दे के पीछे रहता है, ताकि जटिल न हो, लेकिन गीता में निहित है:

1. लेन-देन और WCF संदर्भ के लिए कार्यान्वयन समान है; प्रादुर्भाव Transaction.Current और OperationContete.Current है।
2. यदि संदर्भ डिफ़ॉल्ट (टैफिनिटी) के रूप में आया है, तो हम मानते हैं कि हमें सामान्य नॉनशेयर निर्यात देने की आवश्यकता है
3. किसी वस्तु के निर्माण की अवरोधन - यदि हम एक भाग बनाते हैं, तो हमें इसके साथ कुछ करने की आवश्यकता हो सकती है - उदाहरण के लिए, लेन-देन के लिए, मैं यह जाँचता हूँ कि क्या भाग एक लेनदेन संसाधन है (ISinglePhaseNotification या IEnlistmentNotification) और इसे एक वाष्पशील संसाधन के रूप में लेन-देन से कनेक्ट करें, यदि ऐसा है।
4. एक बंधन को नष्ट करना - एक धागे के लिए ऊपर बताए गए इनिशियलाइज़ेशन में, मैं एक थ्रेड बनाता हूं, जो रेफरेंस एफ़िलिटी को निष्पादित करता है, जो संदर्भ स्ट्रीम समाप्त होने के बाद होता है। एक लेन-देन / संचालन के लिए - मैं सिर्फ लेनदेन / ऑपरेशन पूरा होने के लिए बाध्य हूं।

सभी का धन्यवाद, शायद कोई मदद करेगा।