2010-08-10 19 views
9

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

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

+0

यदि आप केवल नियंत्रण में उलझन चाहते हैं तो आपको लाइब्रेरी की आवश्यकता नहीं है। बस अपनी कक्षा के निर्माता के माध्यम से अपनी निर्भरताओं को इंजेक्ट करें। –

+0

अभी मैं यही कर रहा हूं। हालांकि, तारों की चीजें थोड़ा बोझिल हो रही हैं और मुझे पता है कि यह परियोजना बढ़ने के साथ ही बदतर हो जाएगी। (यह कई घटकों से बना एक कंपाइलर प्रोजेक्ट है और अन्य लोगों के लिए घटकों को स्वैप करना संभव होना चाहिए ...) – Qwertie

+0

मैं रॉबर्ट से सहमत हूं। कोड में निर्भरता इंजेक्शन करके, आपको संकलक का भी लाभ मिलता है। मैं आमतौर पर मुख्य() विधि में अपने आवेदन तार। –

उत्तर

5

मुझे आईओसी ढांचे के बारे में बहुत कुछ लगता है। मैं हर समय आईओसी का उपयोग करता हूं, मुझे सिर्फ फ्रेमवर्क की आवश्यकता नहीं दिखती है।

कहा करने के बाद कि, एक अगर मैं एक लेने के लिए थे मैं प्रयोग करेंगे AutoFac

यह सरल, समझ आसान है, और हल्के महसूस करता होगा।

+0

http://nblumhardt.com/2010/04/introducing-autofac-2-1-rtw/ - कहता है "ऑटोफ़ैक .NET 4.0 में अंतर्निहित समर्थन का उपयोग करता है" – Qwertie

+0

दाएं, ऑटोफ़ैक 2.1 करता है। लेकिन इससे पहले के संस्करणों (4.0) को 4.0 की आवश्यकता नहीं है। यदि आप एक 4.0 एप तैनात कर रहे हैं, तो तथ्य यह अंतर्निहित का उपयोग करता है। नेट सामान एक अच्छी बात है :) – CubanX

+0

मैं वीएस 2008 तक सीमित हूं और इसके अलावा, उपयोगकर्ताओं को अपने .NET Framwork को अपग्रेड करने की आवश्यकता नहीं है। ऐसा लगता है कि ऑटोफैक 2.2 का .NET 3.5 संस्करण है, लेकिन यह 5 डीएलएल और संयुक्त रूप से 5 डीएलएल की तुलना में एक एक्सएमएल फ़ाइल के साथ आता है, मुझे आश्चर्य है कि इसमें से कितना आवश्यक है? – Qwertie

3

Ninject पर एक नज़र डालें।

+0

http://ninject.org/download पर .NET Framework 3.5 डाउनलोड में 6 डीएलएल आधा मेग से अधिक है, जो मैं उम्मीद कर रहा था उससे भारी है। – Qwertie

+3

आपके प्रोजेक्ट में जो भी आप संदर्भित करते हैं वह एकल Ninject.dll असेंबली है जो आपके हल्के मानदंडों को पूरा करता है। एक विस्तार और वेब है। एमवीसी असेंबली सेट जो बेस एन इंजेक्शन कार्यक्षमता के लिए जोड़ती है यदि आपको इसकी आवश्यकता है। –

+0

क्या वे असेंबली वैकल्पिक हैं, या Ninject.dll की आवश्यकता है? क्या एक्सएमएल फाइल की आवश्यकता है? – Qwertie

4

मैं एन इंजेक्शन के अलावा यह भी सुझाव दूंगा कि आप माइक्रोसॉफ्ट के डी फ्रेमवर्क, Unity देखें।

1

StructureMap आज़माएं।

कोर StructureMap.dll बहुत छोटा है।

0

मैं एक बड़ी प्रणाली के साथ काम करता हूं और हमने मैन्युअल रूप से सब कुछ इंजेक्शन दिया है। हम अधिकांश इंजेक्शन/तारों को साफ करने के लिए अमूर्त फैक्ट्री पैटर्न का उपयोग करते हैं और यह ठीक काम करता है।

डी फ्रेमवर्क भरपूर मात्रा में हैं। अतिरिक्त बाह्य निर्भरता लेने से पहले, कुछ अलग-अलग समय पर विचार करें कि एक अलग/नया पैटर्न लागू करने से आपकी समस्याएं हल हो जाएंगी।

संपादित करें: (संभवतः पक्षपाती/अन्यायपूर्ण) कारण मैं एक डि ढांचे इस्तेमाल नहीं किया है:

  • आप एक डि ढांचे का उपयोग करते हैं, तो आप अपने सॉफ्टवेयर के साथ डि ढांचे जहाज करने के लिए है। यह कुछ के लिए एक शो स्टॉपर हो सकता है, और अन्य को अतिरिक्त निर्भरता की योग्यता पर बहस करना पड़ सकता है।
  • आपको अभी भी निर्भरता लेने के लिए रचनाकार बनाना है
  • और आपको अभी भी DI ढांचे पर उपयोग करने के लिए (या कम से कम संकेत) कहना है। एकमात्र बड़ा अंतर यह है कि आप अपने कारखाने के बजाय डी कारखाने का उपयोग कर रहे हैं।

उस कारखाने के निर्माण के लिए, अधिकांश रिफैक्टरिंग टूल आपके लिए बहुत कम कीस्ट्रोक के साथ 90% काम कर सकते हैं।

+1

क्या आपने वास्तव में एक डीआई फ्रेमवर्क का उपयोग किया है? यदि हां, तो क्या आपको लगता है कि यह लायक था इससे ज्यादा परेशानी थी? – Qwertie

+0

मैं यह देखने में असफल रहा कि एक बड़ी प्रणाली में मैन्युअल इंजेक्शन ** डीआई फ्रेमवर्क का उपयोग करके स्वचालित रूप से किया जाने से ** कम काम ** है। –

+0

प्रतिक्रिया एक टिप्पणी के लिए थोड़ा लंबा था, इसके बजाय मेरा जवाब संपादित किया। सूची के लिए –

4

आपके द्वारा पेश किए जाने वाले किसी भी ढांचे को अंततः आपके ऐप की निर्भरता बन जाएगी। इसके अलावा, लोगों के पास हल्के वजन की विभिन्न परिभाषाएं हैं। Unity, या StructureMap या कैसल विंडसर पर एक नज़र डालें क्योंकि वे अधिक लोकप्रिय होते हैं। स्कॉट हंसेलमैन की एक पूरी सूची है, here। अपना चयन ले लो।

+0

+1। तकनीकी रूप से यदि मैं अपने डीएलएल में से एक में आईओसी कंटेनर एम्बेड करता हूं और नामस्थान बदलता हूं, तो यह बाहर से निर्भरता की तरह नहीं लगेगा, साथ ही मुझे कुछ भी हटाने का विकल्प मिलेगा जिसका मैं उपयोग नहीं करता हूं। यह देखते हुए कि वे अपने डिजाइन को कैसे समझाते हैं, मैं सोच रहा हूं (विंडसर) माइक्रोक्रोन उस दृष्टिकोण के लिए उपयुक्त है ... – Qwertie

+1

संदर्भित हंसेलमैन पोस्ट के नीचे @ क्वर्टी, कोड के 15 लाइनों में दो आईओसी कंटेनरों का एक लिंक है। जब आपको "ढांचे" की आवश्यकता नहीं होती है तो उनका उद्देश्य बेहद हल्का होना चाहिए। शायद यह देखने लायक है। –

1

examples on the web आपके स्वयं के कंटेनर लिखने के बारे में हैं, हालांकि वे बहुत बुनियादी हैं और अधिक मजबूत ढांचे द्वारा प्रदान की जाने वाली सुविधाओं की कमी होगी।

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