डी कंटेनर, कारखाना, या क्षणिक वस्तुओं के लिए नया?

Question

उन ऑब्जेक्ट्स से निपटने के लिए जिन्हें केवल रनटाइम पर ज्ञात डेटा की आवश्यकता होती है, जैसे कि उपयोगकर्ता नाम और पासवर्ड, जहां तत्काल ऑब्जेक्ट होना चाहिए: नए, कारखाने में या डी कंटेनर में उपयोग करके?

उदाहरण के लिए, मैं कर सकता है सिर्फ new एक वस्तु एक बार मैं डेटा है:

UserCredentials creds = 
    new UserCredentials(dialog.getUsername(), dialog.getPassword()); 

या, मैं एक कारखाने इस्तेमाल कर सकते हैं:

UserCredentials creds = 
    CredentialsFactory.create(dialog.getUsername(), dialog.getPassword()); 

या, मैं एक के भीतर एक प्रदाता इस्तेमाल कर सकते हैं डी कंटेनर (जो इस मामले में अनिवार्य रूप से एक पैरामीटर संचालित कारखाना होगा)। [नमूना कोड छोड़े गए।]

यह बहुत आसान कुछ के लिए डि कंटेनर का उपयोग करने के लिए दोनों गलत लगता है अभी तक यह भी गलत नहीं लगता है इसकी पूर्णता के साथ इसका इस्तेमाल करने की।

Answer 1

हमेशा की तरह, यह निर्भर करता है, लेकिन एक सामान्य नियम के रूप में, अपने दूसरे विकल्प की तरह एक स्थिर कारखाने केवल शायद ही कभी एक अच्छा विचार है।

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

अन्य मामलों में, आप किस प्रकार बनाने के लिए अपने आप में एक अमूर्त का प्रतिनिधित्व कर सकते करना चाहते हैं। यदि ऐसा है, तो आप new कीवर्ड का उपयोग नहीं कर सकते हैं, लेकिन इसके बजाय सार फैक्टरी का उपयोग करना चाहिए।

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

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

Answer 2

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

यह वास्तव में कब और कहाँ आप इस वस्तु की आवश्यकता होगी और अगर वहाँ एक परिणाम के रूप में अनावश्यक निर्भरता हो जाएगा निर्भर करता है।

Answer 3

यदि आपके पास पहले से ही आपके आवेदन के लिए एक डीआई कंटेनर सेट है तो इस दृष्टिकोण का उपयोग करें। यदि नहीं, तो कारखाने विधि का उपयोग करें।

Answer 4

गूगल परीक्षण ब्लॉग a post which tries to answer this question है। मूल विचार यह है कि आप अपने प्रत्येक वर्ग को "नए" या "इंजेक्शन योग्य" के रूप में वर्गीकृत कर सकते हैं, और यह कि केवल नए "नए" होने के लिए ठीक है। int, string, DateTime, आदि की तरह

• मान:

  मैं "newables" के 2 मुख्य श्रेणियों भेद।

• Customer, Order, Employee, आदि जैसे संस्थाएं। मुझे लगता है कि आपकी UserCredentials कक्षा इस शीर्षक के अंतर्गत आती है।

यह जान लेना newables (परीक्षण योग्य) व्यवहार हो सकता है महत्वपूर्ण है। यदि आप सोचने की गलती करते हैं कि नए उत्पादों में कोई व्यवहार या यूनिट परीक्षण नहीं होना चाहिए, तो आप anemic domain model एंटी-पैटर्न के साथ समाप्त हो जाएंगे।

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

इसके अलावा, नए उत्पादों को इंजेक्टेबल्स के बारे में जानने की अनुमति है, लेकिन वे केवल उनके साथ ट्रांजिटिक सहयोग करते हैं। उदाहरण के लिए, UserCredentials को कन्स्ट्रक्टर तर्क के रूप में IUserDatabase नहीं लेना चाहिए। इसके बजाय, UserCredentials.Verify(IUserDatabase) विधि हो सकती है।

संपादित करें: मैं वर्तमान में ऊपर जो लिखा है उसके बारे में अब इतना निश्चित नहीं हूं। संस्थाओं को उनके कन्स्ट्रक्टर को सीधे कॉल करने के बजाय (इंजेक्शन योग्य) कारखानों के माध्यम से भी बनाया जा सकता है। फैक्ट्री कार्यान्वयन तब इकाई में चीजों को इंजेक्ट कर सकता है।