संस्थाओं / व्यावसायिक वस्तुओं के लिए निर्भरता को हल करने के लिए आईओसी कंटेनर का उपयोग क्यों नहीं किया जाता है?


82

मैं DI के पीछे की अवधारणा को समझता हूं, लेकिन मैं अभी सीख रहा हूं कि विभिन्न IoC कंटेनर क्या कर सकते हैं। ऐसा लगता है कि ज्यादातर लोग आईओसी कंटेनरों का उपयोग करने के लिए स्टेटलेस सेवाओं को तार-तार करने की वकालत करते हैं, लेकिन संस्थाओं जैसे स्टेटफुल ऑब्जेक्ट्स के लिए उनका उपयोग करने के बारे में क्या?

चाहे वह सही हो या गलत, मैं आम तौर पर व्यवहार के साथ अपनी संस्थाओं को सामान करता हूं, भले ही उस व्यवहार के लिए बाहरी वर्ग की आवश्यकता हो। उदाहरण:

public class Order : IOrder
{

    private string _ShipAddress;
    private IShipQuoter _ShipQuoter;

    public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
    {
        // OrderData comes from a repository and has the data needed 
        // to construct order
        _ShipAddress = OrderData.ShipAddress;  // etc.
        _ShipQuoter = ShipQuoter;

    }

    private decimal GetShippingRate()
    {
        return _ShipQuoter.GetRate(this);
    }
}

जैसा कि आप देख सकते हैं, निर्भरताएं इंजेक्टर इंजेक्ट हैं। अब कुछ सवालों के लिए।

  1. क्या यह गलत व्यवहार माना जाता है कि आपकी संस्थाएं शिपक्वाटर जैसी बाहरी कक्षाओं पर निर्भर हैं? अगर इन परिभाषाओं को सही ढंग से समझूं तो इन निर्भरता को खत्म करना मुझे एनीमिक डोमेन की ओर ले जाता है।

  2. क्या इन निर्भरताओं को हल करने और जरूरत पड़ने पर एक इकाई का निर्माण करने के लिए आईओसी कंटेनर का उपयोग करना बुरा अभ्यास है? क्या इसे करना संभव है?

किसी भी जानकारी के लिए धन्यवाद।


3
बस सामान है कि आप की जरूरत है क्योंकि यह आपके काम को आसान बनाता है, इसलिए नहीं कि शायद यह है कि आप इसे कैसे करना चाहिए
Omu

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

जवाबों:


90

पहला प्रश्न उत्तर देना सबसे कठिन है। क्या एंटिटीज को बाहर की कक्षाओं पर निर्भर करना बुरा व्यवहार है? यह निश्चित रूप से सबसे आम बात नहीं है।

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

आप तर्क दे सकते हैं कि अन्य निर्भरता को एंटिटी में इंजेक्ट करने से आप उसी दिशा में (एसआरपी से दूर) खींच लेंगे। दूसरी ओर आप निश्चित रूप से सही हैं कि यदि आप ऐसा नहीं करते हैं, तो पुल एक एनीमिक डोमेन मॉडल की ओर है ।

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

Nouns के बजाय कमांड और ईवेंट के रूप में डोमेन ऑब्जेक्ट को मॉडलिंग करने के लिए हमारा ध्यान केंद्रित करना हमें एक उचित ऑब्जेक्ट-ओरिएंटेड डोमेन मॉडल बनाने में सक्षम बनाता है।

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


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

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

मेरे उदाहरण में शिपक्वाटर एक webservice (जैसे यूपीएस) से एक आदेश के लिए शिपिंग दरों को खींचता है। क्या आप इसे ऐसी सेवा बना सकते हैं जो IOrder को स्वीकार करती है, या आप इसे ऑर्डर ऑब्जेक्ट जैसे आदेश .GetRates का हिस्सा बनाएंगे?
केसी विल्किंस

मैं यह जानने में बहुत समय बिताऊंगा कि मैं पहली जगह में एक समकालिक पुल से कैसे बच सकता हूं। आप और अधिक डेटा को सिंक्रोनस, ब्लॉकिंग फ़ैशन में खींचते हैं, आपका डिज़ाइन जितना भंगुर होता है। इसलिए CQRS ऐसा आकर्षक विकल्प है।
मार्क सीमन

4
ग्रेग के कागज के लिए आपका लिंक मर चुका है। लेकिन यह अभी भी यहां उपलब्ध है । और ऐसा प्रतीत होता है कि यह एक नया संस्करण है।
बोर्नटूकोड

1

मुझे पता है कि यह एक पुरानी पोस्ट है लेकिन जोड़ना चाहते हैं। यदि आप ctor में अमूर्त भंडार में पास करते हैं, तब भी डोमेन एंटिटी को खुद को जारी नहीं रखना चाहिए। मेरे सुझाव का कारण यह नहीं है कि यह SRP का उल्लंघन करता है, यह DDD के एकत्रीकरण के विपरीत है। मुझे समझाएं, DDD स्वाभाविक रूप से गहरे ग्राफ़ के साथ जटिल ऐप्स के लिए अनुकूल है, इसलिए, हम अंतर्निहित "बच्चों" के लिए परिवर्तनों को जारी रखने के लिए समग्र या मिश्रित जड़ों का उपयोग करते हैं, इसलिए जब हम उन व्यक्तिगत बच्चों में दृढ़ता इंजेक्षन करते हैं जो हम बच्चों के संबंध का उल्लंघन करते हैं समग्र या समग्र जड़ जो जीवन चक्र या एकत्रीकरण का "प्रभारी" होना चाहिए। बेशक समग्र जड़ या समुच्चय कायम नहीं होता है यह स्वयं का ग्राफ है। एक अन्य डीडीडी वस्तुओं की निर्भरता को इंजेक्ट करने के साथ है कि एक इंजेक्ट किए गए डोमेन ऑब्जेक्ट में प्रभावी रूप से कोई राज्य नहीं है जब तक कि कोई अन्य घटना उनके राज्य को हाइड्रेट करने के लिए नहीं होती है। कोड के एएनआई उपभोक्ता को डोमेन व्यवहार को पहले init या सेटअप करने के लिए मजबूर किया जाएगा, इससे पहले कि वे व्यापार व्यवहार को लागू कर सकें जो कि एनकैप्सुलेशन का उल्लंघन करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.