DI ऑब्जेक्ट ग्राफ़ बिल्डिंग - तर्क और निर्माण ग्राफ को अलग करना

Question

क्षमा करें अगर यह वास्तव में एक मूल प्रश्न है लेकिन यह वास्तव में मेरे लिए हो रहा है। मुझे वास्तव में डीआई के विचार पसंद हैं, यह वास्तव में मेरे परीक्षण के साथ मेरी मदद करता है लेकिन मुझे लगता है कि मैंने एक ईंट की दीवार को थोड़ा सा मारा है। इसलिए मैं दो प्रकार के होते हैं: तो नियम है कि आप के लिए पूछ निम्नलिखित

Table(ITableCommandRunner tableRunner, 
     IQueryProvider queryProvider, 
     IDataReader reader, 
     string Name) 

अब तालिका वस्तु काफी केवल उन वस्तुओं का उपयोग करता है:

Table 
TableManager 

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

TableManager(ITableCommandRunner tablrunner) 

ठीक है यह ठीक है लेकिन TableManager.OpenTable आदेश में मैं ITableCommandRunner पर खुला तालिका commmand फोन और उसके बाद का निर्माण एक नया टेबल वस्तु वापस पारित करने के लिए की जरूरत है।

public ITable OpenTable(string tableName) 
    { 
     // Call open table command on tablerunner. 
     // I need a IQueryProvider and IDataReader to pass to the table. 
     return new Table<TEntity>(this.tablerunner, provider,reader, tableName); 
    } 

लेकिन अब मेरा खुला तालिका आदेश में मैं एक IDataReader और IQueryProvider करना है। यदि मैं उन्हें टेबलमैनेजर के निर्माता में पास करता हूं, तो यह उल्लंघन नहीं करता है कि "ऑब्जेक्ट्स को केवल एक आंतरिक प्रकार में पास करने के लिए लेना और वास्तव में उनका उपयोग नहीं करना"।

मुझे सच में यकीन नहीं है कि मैं यह कैसे करता हूं। क्या कोई इसमें मेरी सहायता कर सकता है?

मुझे यकीन नहीं है कि मैं ऑब्जेक्ट निर्माण और तर्क कैसे अलग करता हूं।

Answer 1

एक विकल्प TableFactory को कॉन्फ़िगर करना है जो क्वेरी प्रदाता और पाठक को जानता है, और केवल तालिका नाम जानने की आवश्यकता है। फिर आप कारखाने को TableManager पर भेज सकते हैं। दूसरी तरफ, TableManager लगता है कि इसे संभवतः फैक्ट्री होने की जरूरत है - इस मामले में यह आसान प्रदाता और पाठक की आवश्यकता है, भले ही यह शुरू करने के लिए स्पष्ट न हो, भले ही यह उन्हें पास कर रहा हो ।

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

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

क्षमा करें उस पर एक cheerier दृष्टिकोण है करने के लिए नहीं है, लेकिन यहां तक ​​कि अगर इन विचारों को बहुत-बहुत मदद नहीं कर कम से कम आप जानते हैं कि तुम अकेले नहीं हो :)

Answer 2

आप provider और reader पर पैरामीटर के रूप में जोड़ा जा सका OpenTable()?

OpenTable() पर कॉल कौन कर रहा है? क्या कॉलर provider और reader जानता है ताकि यह उन्हें विधि में पास कर सके?