2011-01-19 13 views
15

मैं अपना दूसरा वास्तविक जीवन आवेदन लिख रहा हूं, जो डीआई का उपयोग करता है। कुल मिलाकर मुझे लगता है कि यह एक बेहतर डिजाइन करने दिया है। लेकिन कुछ कोड गंध हैं, कि मुझे नहीं पता कि कैसे हल करें।DI: इंजेक्ट करने के लिए कितना?

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

मैं "सर्वोत्तम प्रथाओं" या "अंगूठे का नियम" ढूंढ रहा हूं, आम तौर पर मैं सबकुछ इंजेक्ट करता हूं, जो नेट फ्रेमवर्क में नहीं है, क्या यह अधिक है?

चीजें प्राप्त करने के लिए शुरू कर दिया, यहां वस्तुओं है कि मैं इंजेक्षन के दो उदाहरण हैं, लेकिन के बारे में अनिश्चित हूँ।

वस्तुओं है कि आवेदन विन्यास या उन छोटे util वर्गों की तरह सच एकमात्र हैं, तो आप उन्हें इंजेक्षन करते हैं? उन्हें अक्सर इंजेक्शन लगते हैं, उन्हें इंजेक्ट करने का एकमात्र कारण परीक्षण के लिए मूल्य बदलने की अनुमति देता है, लेकिन आयुर्वेद ने किसी अन्य तरीके से समस्या हल कर दी है: http://ayende.com/Blog/archive/2008/07/07/Dealing-with-time-in-tests.aspx

लॉगिंग जैसे सामान्य वस्तुएं, जिनका उपयोग लगभग हर ऑब्जेक्ट में किया जाता है, उन्हें इंजेक्शन दिया जाना चाहिए?

उत्तर

3

अंगूठे का मेरा व्यक्तिगत नियम यह है:

  • यह इंजेक्षन अगर आप इसे अपरिवर्तनीय
  • यह इंजेक्षन अगर आप परीक्षण प्रयोजनों के लिए यह विकल्प सक्षम होना चाहते हैं होना चाहता हूँ

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

वालों इंजेक्ट किया जा सकता है?

करने का कोई कारण नहीं है। लॉगर्स आमतौर पर एक स्थिर वर्ग के माध्यम से उजागर होते हैं, और कॉन्फ़िगरेशन प्रविष्टियों से नए होते हैं, इसलिए परीक्षण उद्देश्यों के लिए भी उन्हें इंजेक्ट करने की आवश्यकता नहीं होती है।

क्या सही कॉन्फ़िगरेशन जैसे अनुप्रयोग कॉन्फ़िगरेशन इंजेक्शन किया जाना चाहिए?

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

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

+2

फिर अपने वर्ग पूरे पर निर्भर करता है उस वस्तु का और कहीं और उपयोग करना मुश्किल होगा। कॉन्फ़िगरेशन के विशिष्ट भाग को इंजेक्ट करने के लिए बेहतर है कि आपकी ऑब्जेक्ट परवाह है। –

12

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

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

मैं निर्माता इंजेक्शन का उपयोग करना पसंद है और अक्सर देखा है कि मैं के बारे में 5 या अधिक वस्तुओं की जरूरत है निर्माता में इंजेक्ट किया जा करने के लिए।

जैसा कि आपने पहले से ही स्वयं को नोट किया है, SRP का पालन न करने के कारण कई निर्भरताएं हो सकती हैं। हालांकि, आप आम निर्भरताओं को समूहीकृत कर रहे हैं, जिसमें कुल सेवा में तर्क है और उपभोक्ताओं में इंजेक्ट करें। मार्क सीमैन के लेख को Aggregate Services के बारे में भी देखें।

वस्तुओं कि आवेदन विन्यास या उन छोटे util वर्गों की तरह सच एकमात्र हैं, तो आप उन्हें इंजेक्षन करते हैं?

मैं व्यक्तिगत रूप से जिस तरह से Ayende यह प्रस्ताव के एक प्रशंसक नहीं हूँ। यह एक Ambient Context है, जो service locator निर्माण का एक विशिष्ट प्रकार है। ऐसा करने से निर्भरता छिप जाती है, क्योंकि कक्षाएं उस स्थैतिक वर्ग को बिना इंजेक्ट किए बगैर कॉल कर सकती हैं। स्पष्ट रूप से इंजेक्शन करने से यह बहुत स्पष्ट हो जाता है कि आपको यूनिट परीक्षण समय की आवश्यकता होती है। इसके अलावा, एमएसटीएस्ट जैसे ढांचे के लिए परीक्षण लिखना मुश्किल हो जाता है जो समानांतर में परीक्षण चलाते हैं। किसी भी countermeasures के बिना, यह आपके परीक्षणों को बहुत अविश्वसनीय बनाता है। एक बेहतर समाधान - DateTime.Now उदाहरण के लिए- इंटरफ़ेस होना चाहिए, जैसा कि here सुझाया गया है। जैसा कि आप देख सकते हैं, वह उत्तर आयेंड दृष्टिकोण से बहुत अधिक है, जो एक ही SO प्रश्न में दिखाया गया है।

इस तरह के प्रवेश के रूप में

आम वस्तुओं, कि लगभग हर वस्तु में उपयोग किया जाता, वे इंजेक्शन किया जाना चाहिए?

मैं उन्हें अपने कोड में इंजेक्ट करता हूं, क्योंकि इससे निर्भरता स्पष्ट हो जाती है। ध्यान दें, हालांकि, मेरे कोड में मुझे अभी भी कभी भी लॉगर इंजेक्ट करना पड़ता है। आप जिस लाइन को लॉग करना चाहते हैं उसके बारे में कठिन सोचें और यह वास्तव में विफलता नहीं है (या एक क्रॉस-कटिंग चिंता जिसे कहीं और रखा जाना चाहिए)। मैं आमतौर पर एक अपवाद फेंक देता हूं जब कुछ ऐसा हुआ जो मुझे उम्मीद नहीं थी। यह मुझे तेजी से बग खोजने की अनुमति देता है। या इसे दूसरे शब्दों में डालने के लिए: फ़िल्टर न करें, लेकिन तेजी से विफल हो जाएं। और कृपया अपने आप से पूछें: "Do I log too much?"

मुझे उम्मीद है कि इससे मदद मिलती है।

3

एक अच्छा प्रारंभिक बिंदु Volatile Dependencies इंजेक्ट करना है।

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

के संबंध में निर्माता से अधिक इंजेक्शन, यह वास्तव में सिर्फ SRP तोड़ने का एक लक्षण है: यह संबंधित सवाल देखें: आप एक वैश्विक (या स्थिर) के रूप में आवेदन विन्यास का उपयोग करते हैं How to avoid Dependency Injection constructor madness?

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