क्या हमें DI के लिए इंटरफेस चाहिए?

Question

मेरे पास एएसपीनेट कोर एप्लिकेशन है। एप्लिकेशन में कुछ सहायक वर्ग हैं जो कुछ काम करते हैं। प्रत्येक वर्ग में अलग हस्ताक्षर विधि होती है। मैं बहुत सारे नेट नेट उदाहरण ऑनलाइन देखता हूं जो प्रत्येक वर्ग के लिए इंटरफेस बनाते हैं और फिर डी फ्रेमवर्क के साथ प्रकार पंजीकृत करते हैं। उदाहरण के लिए

public interface IStorage 
{ 
    Task Download(string file); 
} 

public class Storage 
{ 
    public Task Download(string file) 
    { 
    } 
} 

public interface IOcr 
{ 
    Task Process(); 
} 

public class Ocr:IOcr 
{ 
    public Task Process() 
    { 

    } 
} 

असल में प्रत्येक इंटरफ़ेस के लिए केवल एक वर्ग है। तो फिर मैं के रूप में

services.AddScoped<IStorage, Storage>(); 
services.AddScoped<IOcr,Ocr>(); 

डि साथ इन प्रकार के रजिस्टर लेकिन मैं इंटरफेस होने इसलिए यहाँ इंटरफेस बेमानी लग रही बिना प्रकार रजिस्टर कर सकते हैं। उदाहरण के लिए

services.AddScoped<Storage>(); 
services.AddScoped<Ocr>(); 

तो क्या मुझे वास्तव में इंटरफेस की आवश्यकता है?

Answer 1

नहीं, आप निर्भरता इंजेक्शन के लिए इंटरफेस की आवश्यकता नहीं है। लेकिन आपको उनका इस्तेमाल करना चाहिए!

जैसा कि आपने बताया है, आप सेवा संग्रह के साथ ठोस प्रकार पंजीकृत कर सकते हैं और एएसपी.नेट कोर उन्हें आपकी कक्षाओं में ठीक से इंजेक्ट करेगा। new Storage() के साथ उदाहरण बनाने के लिए आपको प्राप्त होने वाला एकमात्र लाभ service lifetime management (क्षणिक बनाम स्कॉप्ड बनाम सिंगलटन) है।

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

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

Answer 2

क्या यह काम करता है? हाँ। क्या आपको यह करना चाहिए? सं

निर्भरता इंजेक्शन निर्भरता उलट के सिद्धांत के लिए एक उपकरण है: "। कपोल-कल्पना पर निर्भर करते हैं, [नहीं] concretions" https://en.wikipedia.org/wiki/Dependency_inversion_principle

या के रूप में यह SOLID में वर्णित है

एक चाहिए

आप बस जगह पर कंक्रीट कक्षाओं को इंजेक्ट कर सकते हैं और यह काम करेगा। लेकिन यह नहीं है कि DI को प्राप्त करने के लिए डिज़ाइन किया गया था ई।

Answer 3

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

public class Storage 
{ 
    public virtual Task Download(string file) 
    { 
    } 
} 


public class DiskStorage: Storage 
{ 
    public override Task Download(string file) 
    { 
    } 
} 

और: उदाहरण के लिए

services.AddScoped<Storage, DiskStorage>();