2011-02-05 12 views
12

क्या किसी को ऑटोफैक और क्वार्ट्ज.Net एकीकृत करने का कोई अनुभव है? यदि हां, तो जीवन भर प्रबंधन को नियंत्रित करना सबसे अच्छा क्यों है - IJobFactory, IJob के निष्पादन के भीतर, या ईवेंट श्रोताओं के माध्यम से?ऑटोफैक और क्वार्ट्ज.Net एकीकरण


अभी, मैं IJob उदाहरण बना के लिए एक कस्टम autofac IJobFactory उपयोग कर रहा हूँ, लेकिन मैं किसी भी महंगा संसाधन है कि इंजेक्ट किया जाता सुनिश्चित करने के लिए IJobFactory में एक ILifetimeScope करने के लिए प्लग करने के लिए एक आसान तरीका नहीं है IJob में साफ कर रहे हैं। नौकरी कारखाना सिर्फ नौकरी का एक उदाहरण बनाता है और इसे वापस करता है। यहाँ मेरे वर्तमान विचार कर रहे हैं (उम्मीद वहाँ बेहतर होते हैं ...)

  • ऐसा लगता है कि सबसे AutoFac एकीकरण किसी भी तरह काम की इकाई वे बनाने के चारों ओर एक ILifetimeScope लपेट दें। स्पष्ट ब्रूट फोर्स तरीका ILifetimeScope को IJob में पास करना प्रतीत होता है और Execute विधि ILifetimeScope बच्चे बनाते हैं और वहां किसी भी निर्भरता को तुरंत चालू करते हैं। यह एक सेवा लोकेटर पैटर्न के बहुत करीब लगता है, जो बदले में ऑटोफैक की भावना के खिलाफ जाता है, लेकिन यह एक दायरे के उचित संचालन को सुनिश्चित करने का सबसे स्पष्ट तरीका हो सकता है।

  • मैं नौकरी निष्पादन स्टैक के विभिन्न चरणों को संभालने के लिए कुछ क्वार्ट्ज घटनाओं में प्लग कर सकता हूं, और वहां जीवनभर प्रबंधन को संभाला जा सकता हूं। यह शायद बहुत अधिक काम होगा, लेकिन संभवतः इसके लायक है अगर यह चिंताओं को क्लीनर अलगाव प्राप्त करता है।

  • सुनिश्चित करें कि एक IJob एक IServiceComponent प्रकार है, जो सब काम करना होगा चारों ओर एक सरल आवरण है, और Owned<T>, या Func<Owned<T>> के रूप में यह अनुरोध करते हैं। मुझे यह पसंद है कि ऑटोफैक के साथ यह कैसे दिखता है, लेकिन मुझे यह पसंद नहीं है कि यह IJob के सभी कार्यान्वयनकर्ताओं के लिए सख्ती से लागू नहीं है।

उत्तर

12

Quartz.Net और IJob रों बारे में बहुत ज्यादा जानने के बिना, मैं एक सुझाव अभी भी उपक्रम होगा।

public class JobWrapper<T>: IJob where T:IJob 
{ 
    private Func<Owned<T>> _jobFactory; 

    public JobWrapper(Func<Owned<T>> jobFactory) 
    { 
     _jobFactory = jobFactory; 
    } 


    void IJob.Execute() 
    { 
     using (var ownedJob = _jobFactory()) 
     { 
      var theJob = ownedJob.Value; 
      theJob.Execute(); 
     } 
    } 
} 

निम्नलिखित पंजीकरण को देखते हुए:

var job = _container.Resolve<JobWrapper<SomeJob>>(); 

नोट:: एक

builder.RegisterGeneric(typeof(JobWrapper<>)); 
builder.RegisterType<SomeJob>(); 

एक काम कारखाने अब इस आवरण को हल कर सकता है

निम्नलिखित नौकरी आवरण पर विचार करें lifetime scope cre होगा ownedJob उदाहरण के हिस्से के रूप में, जो इस मामले में Owned<SomeJob> प्रकार है। SomeJob द्वारा या InstancePerDependency द्वारा आवश्यक किसी भी निर्भरता को Owned उदाहरण के साथ बनाया और नष्ट कर दिया जाएगा।

+0

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

+0

@dfaivre - मैंने अपने कोड में एक बग को सही किया है, मैं 'ownedJob.Value' भाग भूल गया था। शायद मेरे इरादे अब स्पष्ट हैं। –

+3

मुझे नहीं पता था कि स्वामित्व ने एक गुंजाइश बनाई है; बहुत उपयोगी। मुझे लगता है कि यह क्वार्ट्ज स्टैक में गहरे गोता के बिना शायद सबसे सीधा आगे दृष्टिकोण है। यदि नौकरी 'जॉबवापर <>' प्रकार की नहीं है (बस इतना मैं रात में थोड़ा बेहतर सोता हूं) तो मैं शायद 'आईजोब फैक्ट्री' को फेंक दूंगा। महान अंतर्दृष्टि के लिए फिर से धन्यवाद। –

संबंधित मुद्दे