Brauchen wir Schnittstellen für DI?

Question

Ich habe asp.net Core-Anwendung. Die Anwendung hat wenige Hilfsklassen, die etwas Arbeit leisten. Jede Klasse hat eine andere Signaturmethode. Ich sehe viele Online-Core-Beispiele online, die eine Schnittstelle für jede Klasse erstellen und dann Typen mit dem DI-Framework registrieren. Zum Beispiel

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() 
    { 

    } 
} 

Grundsätzlich für jede Schnittstelle gibt es nur eine Klasse. Dann registriere ich diese Typen mit DI als

Aber ich kann Typ ohne Schnittstellen registrieren, so dass Schnittstellen hier redundant aussehen. zB

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

Also brauche ich wirklich Schnittstellen?

Answer 1

Nein, Sie brauchen nicht benötigen Schnittstellen für Abhängigkeitsinjektion. Aber du solltest sie benutzen!

Wie Sie bereits erwähnt haben, können Sie konkrete Typen mit der Service-Sammlung registrieren, und ASP.NET Core wird sie problemlos in Ihre Klassen einspeisen. Der einzige Vorteil, den Sie haben, wenn Sie einfach Instanzen mit new Storage() erstellen, ist service lifetime management (transient vs. Scoped vs. Singleton).

Das ist nur ein Teil der Macht der Verwendung von DI, obwohl. Wie @DavidG sagte, ist der Hauptgrund, warum Interfaces so oft mit DI gepaart werden, der Test. Wenn Sie Ihre Klassen von Interfaces (Abstraktionen) anstatt von anderen konkreten Klassen abhängig machen, können Sie sie viel einfacher testen.

Für Ihre Tests können Sie eine MockStorage erstellen, die IStorage implementiert, und Ihre Verbraucherklasse sollte nicht in der Lage sein, den Unterschied zu erkennen. Oder Sie können ein spöttisches Framework verwenden, um einfach eine abgespeckte IStorage zu erstellen. Verspottungs-Frameworks unterstützen entweder nicht das Betonen konkreter Klassen oder es ist sehr umständlich. Schnittstellen sind viel einfacher und sauberer.

Answer 2

Funktioniert es? Ja. Sollten Sie es tun? Nr

Dependency Injection ist ein Werkzeug für das Prinzip der Abhängigkeit Inversion „. Hängen von Abstraktionen, [nicht] concretions“ https://en.wikipedia.org/wiki/Dependency_inversion_principle

Oder wie es in SOLID

sollte beschrieben ist

Sie können nur Beton Klassen überall injizieren und es wird funktionieren.Aber es ist nicht das, was DI entwickelt wurde, um zu erreichen e.

Answer 3

Ich werde nicht versuchen zu decken, was andere bereits erwähnt haben, die Verwendung von Schnittstellen mit DI wird oft die beste Option sein. Aber es ist erwähnenswert, dass die zeitweise Verwendung der Objektvererbung eine weitere nützliche Option bietet. So zum Beispiel:

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


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

und es wie so Registrierung:

services.AddScoped<Storage, DiskStorage>();