अनुप्रयोगों में साझा लाइब्रेरी के साथ DI का उपयोग

Question

मुझे एक डिज़ाइन चुनौती का सामना करना पड़ रहा है जिसे मैं संतोषजनक तरीके से हल नहीं कर सकता। मेरे पास एक क्लास लाइब्रेरी असेंबली है जिसमें मेरी सभी साझा ओआरएम ऑब्जेक्ट्स हैं (एंटीटीस्पेस फ्रेमवर्क का उपयोग करके)। इन वस्तुओं का उपयोग 2 या अधिक विभिन्न अनुप्रयोगों में किया जाता है, यही कारण है कि वे अपनी स्वयं की असेंबली में हैं। इस सेटअप ने मेरे लिए 4+ साल के लिए ठीक काम किया है।

मेरे पास माइक्रोसॉफ्ट के पैटर्न & प्रैक्टिस समूह (पी पी) से समग्र एप्लिकेशन ब्लॉक (सीएबी) पर निर्मित कुछ एप्लिकेशन भी हैं। हां, मुझे पता है कि यह वास्तव में पुराना है, लेकिन मैं एक अंशकालिक डेवलपर हूं, एक व्यक्ति की दुकान है और वर्तमान ढांचे के लिए अद्यतन करने का जोखिम नहीं उठा सकता है।

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

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

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

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

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

इसके अलावा, मैं वर्तमान प्रौद्योगिकियों पर हिप नहीं हूं जो वास्तव में बाहर हैं और वास्तव में, ईमानदार होने के लिए केवल उन लोगों को समझते हैं जिन्हें मैं वर्तमान में उपयोग कर रहा हूं। तो अगर मैंने कुछ विरोधाभासी या भ्रमित कहा है, तो मुझे आशा है कि आप जो कुछ भी पूछ रहे हैं उसे पाने के लिए आप बाकी पद से पर्याप्त समझ सकते हैं।

Answer 1

ऐसा लगता है कि आप Single Responsibility Principle तोड़ रहे हैं।

ए Person ऑब्जेक्ट को केवल एक व्यक्ति रिकॉर्ड के लिए डेटा रखना चाहिए। सेवाओं को Person ऑब्जेक्ट में ले जाएगा और Person ऑब्जेक्ट पर विधियों के बजाय इसे हेरफेर करने के बजाय उस हेरफेर किया था।

इसका एक उत्कृष्ट उदाहरण Person ऑब्जेक्ट को पॉप्युलेट कर देगा। आइए कहें ऐप ए वेब सेवा से डेटा पकड़ लेता है, और ऐप बी डेटाबेस से पकड़ लेता है। इन मामलों में मेरे पास Storage सेवा का कुछ प्रकार होगा जिसे आप अपना Person ऑब्जेक्ट प्राप्त करने के लिए कहते हैं। फिर उस संग्रह का कार्यान्वयन प्रत्येक एप्लिकेशन के लिए विशिष्ट हो सकता है, और आपके साझा असेंबली में एक सामान्य इंटरफ़ेस रखने की कोशिश करने के बजाय, ऐप द्वारा अपने आईओसी में डाल दिया जा सकता है।

Answer 2

मैं इसे संबोधित करने के लिए कुछ दृष्टिकोणों के बारे में सोच सकता हूं।

• अलग-अलग व्यक्ति/एप्लिकेशन को अलग-अलग व्यवहार को अलग करें। एप्लिकेशन में सेटटर का उपयोग करके निर्भरता इंजेक्शन करें।

Apporach1

---

public interface IPerson 
{ 
IPersonApp1 Person1 {get; set;} 
IPersonApp2 person2 {get; set;} 
} 

class Person : IPerson 
{ 
IPerson1 Person1 {get; set;} 
IPerson2 Person2 {get; set;} 
} 

---

public interface IPerson1 
    { 
    // App1 specific behavior here 
    void App1SpecificMethod1(); 
    } 
    class Person1: IPerson1 
    { 
    void App1SpecificMethod1() 
     { 
     // implementation 
     } 
    } 

class App1 
{ 
    IPerson objPerson; 
    // Dependency injection using framework 
    App1(IPerson objPerson) 
    { 
    this.objPerson = objPerson; 
    // Dependency injection using setter 
    this.objPerson.Person1 = new Person1(); 
    } 
} 

---

• व्यवहार प्रत्येक व्यक्ति/आवेदन अलग से करने के लिए विशिष्ट बाहर अलग। व्यक्ति कन्स्ट्रक्टर में निर्भरता इंजेक्शन करें।

Apporach2

---

class Person : IPerson 
{ 
IPerson1 Person1 {get; private set;} 
IPerson2 Person2 {get; private set;} 
// DI through constructor. If the type IPerson1 or IPerson2 are not registered, it will be set to null. 
Person(IPerson1 objPerson1, IPerson2 objPerson2) 
{ 
    this.Person1 = objPerson1; 
    this.Person2 = objPerson2; 
} 
} 

व्यक्ति इंटरफेस परियोजना IPerson1 और IPerson2 के संदर्भ की आवश्यकता है या आप व्यक्ति इंटरफेस परियोजना अपने आप में IPerson1 और IPerson2 घोषणा कर सकते हैं।

Answer 3

मैं इस पर कैमरून मैकफ़ारलैंड से सहमत हूं: आप एसआरपी तोड़ रहे हैं।

बेशक

OO डिजाइन का एक प्रमुख पहलू डेटा वे साथ काम करने के करीब आपरेशन डाल रहा है, इसका मतलब है कि मेरी ORM वस्तुओं कार्यक्षमता उन्हें जहां उचित

जोड़ा की आवश्यकता है

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