सी # कन्स्ट्रक्टर और निर्भरता इंजेक्शन

Question

मैं जानना चाहता हूं कि डीटीओ वस्तुओं के रचनाकारों को डिजाइन करने में सबसे अच्छा अभ्यास क्या है।

कहना मैं इस तरह की एक Dto वस्तु है:

मैं एक निर्माता की घोषणा कर सकता है:

public CustomerDto(string name, string surname, string phone, ...) 
{ 
    this.Name = name; 
    this.Surname = surname; 
    this.Phone = phone; 
    ... 
} 

जब आप यह देख

class CustomerDto 
{ 
    public string Name { get; set; } 
    public string Surname { get; set; } 
    public string Phone { get; set; } 
    ... 
} 

वहाँ वस्तु के निर्माण के लिए कई तरीके हैं कन्स्ट्रक्टर और तत्काल एक एसआरपी (एकल जिम्मेदारी) उल्लंघन का निष्कर्ष निकाला?

भले ही ये गुण सभी संबंधित हैं।

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

सी # में हम भी अधिक सुंदर ढंग से इस वस्तु का निर्माण कर सकते हैं:

var dto = new CustomerDto() 
{ 
    Name = "Some name", 
    Surname = "Some surname" 
} 

या एक धाराप्रवाह बिल्डर या इस तरह के NBuilder के रूप में एक रूपरेखा का उपयोग करें।

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

कृपया मुझे यह समझाने में मदद करें कि कौन सा बेहतर तरीका है।

Answer 1

आपके उदाहरणों में वैल्यू प्रकार निर्भरता नहीं हैं। एक निर्भरता उपभोक्ता को कार्यक्षमता (या कॉन्फ़िगरेशन) प्रदान करती है। आपके मामले में वे केवल सामान्य मान हैं जो आपके डीटीओ को सौंपा गया है। जब तक डेटा एकसाथ हो, तब तक आप एसआरपी का उल्लंघन नहीं करते हैं भले ही आप कन्स्ट्रक्टर में बहुत से मूल्य आवंटित करते हैं। इस मामले में एक ही जिम्मेदारी डेटा पकड़ना है।

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

यदि किसी कन्स्ट्रक्टर या गुणों का उपयोग करके मान निर्दिष्ट करना बेहतर है तो उपयोग पर निर्भर करता है। यदि उन्हें आवश्यक है तो कन्स्ट्रक्टर संस्करण बेहतर है। यदि वे वैकल्पिक हैं तो संपत्ति का तरीका बेहतर है।

Answer 2

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

तो मैं पसंद करते हैं:

public CustomerDto(string name, string surname, string phone, ...) 

डीटीओ एक डाटा ट्रांसफर वस्तु है, विशेष रूप से सम्पत्तियों का एक समूह का प्रतिनिधित्व करने के लिए एक प्रणाली (के रूप में अच्छी तरह से वितरित) सीमाओं के पार पारित होने के लिए है, इसलिए बहुत ज्यादा SRP के बारे में परेशान नहीं करते उल्लंघन। यह फेकाडे डिजाइन पैटर्न की तरह है, यह उपयोग को सरल बनाने के लिए संचालन/सेवाओं का एक सेट abstarcts। तो इस केज़ में Keep It Simple जीता।