it-swarm.com.de

Inversion der Kontrolle vs. Abhängigkeitsinjektion

Nach dem Papier von Martin Fowler ist die Umkehrung der Steuerung das Prinzip, bei dem der Steuerungsfluss eines Programms umgekehrt wird: Anstatt dass der Programmierer den Fluss eines Programms steuert, werden die externen Quellen (Framework, Services, andere Komponenten) ) übernimm die Kontrolle darüber. Es ist, als würden wir etwas in etwas anderes einstecken. Er erwähnte ein Beispiel zu EJB 2.0:

Zum Beispiel die Session Bean-Schnittstelle definiert ejbRemove, ejbPassivate (im Sekundärspeicher gespeichert) und ejbActivate (aus passivem Zustand wiederhergestellt). Sie können nicht kontrollieren, wann Diese Methoden heißen genau was tun sie. Der Container ruft uns an, wir nenn es nicht.

Dies führt zu dem Unterschied zwischen Framework und Bibliothek:

Inversion der Kontrolle ist ein wesentlicher Bestandteil von Was unterscheidet ein Framework von einem Bibliothek. Eine Bibliothek ist im Wesentlichen eine Funktionssatz, den Sie aufrufen können, heutzutage normalerweise organisiert in Klassen. Jeder Anruf erledigt und __. gibt die Kontrolle an den Client zurück.

Ich denke, der Standpunkt, dass DI IOC ist, bedeutet, dass die Abhängigkeit eines Objekts umgekehrt ist: Stattdessen steuert es seine eigenen Abhängigkeiten, seinen Lebenszyklus ... etwas anderes tut es für Sie. Aber wie Sie mir von Hand mit DI erzählt haben, ist DI nicht unbedingt IOC. Wir können immer noch DI und keine IOC haben.

In diesem Dokument (aus der Pococapsule, other IOC Framework für C/C++) wird jedoch vorgeschlagen, dass wegen IOC und DI die IOC Container und DI-Frameworks sind J2EE weit überlegen, da J2EE den Framework-Code in die Komponenten mischt und ihn nicht zu einem einfachen alten Java/C++ - Objekt (POJO/POCO) macht.

Inversion von Kontrollcontainern außer dem Abhängigkeitseinspritzmuster (Archivlink)

Weitere Informationen, um zu verstehen, was das Problem mit dem alten Component-Based Development Framework ist, das zum zweiten Artikel oben führt: Warum und was von Inversion of Control (Archivlink)

Meine Frage: Was genau ist IOC und DI? Ich bin verwirrt. Basierend auf pococapsule ist IOC etwas bedeutender als nur die Steuerung zwischen Objekten oder Programmierern und Frameworks zu invertieren.

410
Amumu

IoC ist ein allgemeiner Begriff, der bedeutet, dass die Anwendung die Methoden nicht in einem Framework aufruft. Das Framework ruft Implementierungen auf, die von der Anwendung bereitgestellt werden.

DI ist eine Form von IoC, bei der Implementierungen über Konstruktoren/Setter/Services-Lookups an ein Objekt übergeben werden, von denen das Objekt abhängig ist, um sich korrekt zu verhalten.

IoC ohne DI wäre beispielsweise das Template-Muster, da die Implementierung nur durch Unterklassifizierung geändert werden kann.

DI-Frameworks dienen der Verwendung von DI und können Schnittstellen (oder Anmerkungen in Java) definieren, um die Implementierung der Implementierungen zu erleichtern.

IoC-Container sind DI-Frameworks, die außerhalb der Programmiersprache arbeiten können. In einigen können Sie konfigurieren, welche Implementierungen in Metadatendateien (z. B. XML) verwendet werden sollen, die weniger invasiv sind. Bei einigen können Sie IoC-Vorgänge durchführen, die normalerweise nicht möglich sind, z. B. eine Implementierung an pointcuts .

Siehe auch diesen Martin Fowlers Artikel .

529
Garrett Hall

Kurz gesagt, IoC ist ein viel weiter gefasster Begriff, der DI einschließt, aber nicht darauf beschränkt ist

Der Begriff Inversion of Control (IoC) bedeutete ursprünglich jede Art von Programmierstil, bei dem ein Gesamt-Framework oder eine Laufzeit den Programmfluss kontrollierten

Bevor DI einen Namen hatte, begannen die Leute, Frameworks zu bezeichnen, die Abhängigkeiten als Inversion von Kontrollcontainern verwalten, und bald wurde die Bedeutung von IoC allmählich zu dieser bestimmten Bedeutung: Inversion der Kontrolle über Abhängigkeiten.

Inversion of Control (IoC) bedeutet, dass Objekte keine anderen Objekte erstellen, auf die sie sich bei ihrer Arbeit verlassen. Stattdessen erhalten sie die Objekte, die sie benötigen, von einer externen Quelle (z. B. einer XML-Konfigurationsdatei).

Dependency Injection (DI) bedeutet, dass dies ohne den Eingriff des Objekts erfolgt, normalerweise durch eine Framework-Komponente, die Konstruktorparameter und gesetzte Eigenschaften übergibt.

183
Tomasz Jaskuλa

DI ist eine Teilmenge von IoC

  • IoC bedeutet, dass Objekte keine anderen Objekte erstellen, auf die sie sich bei ihrer Arbeit verlassen. Sie erhalten stattdessen die Objekte, die sie benötigen, von einem externen Dienst (z. B. XML-Datei oder einzelner App-Dienst). 2 Implementierungen von IoC, die ich verwende, sind DI und ServiceLocator.
  • DI bedeutet, dass das IoC-Prinzip, abhängige Objekte zu erhalten, ohne Verwendung konkreter Objekte, jedoch ohne Abstraktionen (Schnittstellen) ausgeführt wird. Dies macht alle Komponentenketten überprüfbar, da die Komponente höherer Ebene nicht nur von der Komponente der unteren Ebene abhängt. Mocks implementieren diese Schnittstellen.

Hier sind einige andere Techniken, um IoC zu erreichen .

39

 enter image description here
Quelle

IoC (I nversion o f C ontrol): - Dies ist ein allgemeiner Begriff und wird auf verschiedene Arten implementiert (Ereignisse, Delegierte usw.).

DI (D ependency I Njection): - DI ist ein Subtyp von IoC und wird von Konstruktor-Injektion, Setter-Injektion oder Schnittstellen-Injektion) implementiert.

Spring unterstützt jedoch nur die folgenden zwei Typen: 

  • Setter-Injektion
    • Setter-basiertes DI wird durch Aufrufen von Setter-Methoden für die Beans des Benutzers nach dem Aufrufen eines Konstruktors ohne Argumente oder einer statischen Factory-Methode ohne Argumente zur Instantiierung des Beans realisiert.
  • Konstruktor-Injektion
    • Konstruktor-basiertes DI wird durch Aufrufen eines Konstruktors mit einer Reihe von Argumenten realisiert, die jeweils einen Collaborator darstellen. Hiermit können wir überprüfen, dass die injizierten Beans nicht null sind und schnell ausfallen (Fehler beim Kompilieren und nicht zur Laufzeit) Beim Start der Anwendung erhalten wir NullPointerException: bean does not exist. Konstruktorinjektion ist die beste Methode, um Abhängigkeiten zu injizieren.
22
Premraj

IOC (Inversion von Controller) : Wenn Sie dem Container die Kontrolle über das Abrufen einer Instanz des Objekts geben, wird dies als Inversion von Control bezeichnet. Das heißt, Sie erstellen stattdessen ein Objekt mit dem neuen Operator mach das für dich.

DI (Abhängigkeitsinjektion) : Die Art des Injizierens von Eigenschaften in ein Objekt wird als Abhängigkeitsinjektion bezeichnet.

We have three types of Dependency injection
    1)  Constructor Injection
    2)  Setter/Getter Injection
    3)  Interface Injection

Spring unterstützt nur Constructor Injection und Setter/Getter Injection.

13
kn3l

IoC - Inversion der Kontrolle ist ein generischer Begriff, unabhängig von der Sprache. Es werden eigentlich keine Objekte erstellt, sondern beschrieben, in welchem ​​Modeobjekt ein Objekt erstellt wird.

DI- Abhängigkeit Injection ist ein konkreter Begriff, in dem wir Abhängigkeiten des Objekts zur Laufzeit durch Verwendung verschiedener Injektionstechniken bereitstellen, d. h. Setter-Injektion, Konstruktor-Injektion oder Interface-Injektion.

5
Rahul Gupta

Da alle Antworten theoretisch im Vordergrund stehen, möchte ich sie an einem Beispiel demonstrieren:

Angenommen, wir erstellen eine Anwendung, die eine Funktion zum Senden von SMS Bestätigungsnachrichten enthält, sobald die Bestellung versandt wurde .. _ Wir haben zwei Klassen, von denen eine für das Senden von SMS (SMSService) zuständig ist. und ein anderer, der für die Erfassung der Benutzereingaben verantwortlich ist (UIHandler), sieht unser Code wie folgt aus:

public class SMSService
{
    public void SendSMS(string mobileNumber, string body)
    {
        SendSMSUsingGateway(mobileNumber, body);
    }

    private void SendSMSUsingGateway(string mobileNumber, string body)
    {
        /*implementation for sending SMS using gateway*/
    }
}

public class UIHandler
{
    public void SendConfirmationMsg(string mobileNumber)
    {
        SMSService _SMSService = new SMSService();
        _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
    }
}

Die oben genannte Implementierung ist nicht falsch, aber es gibt einige Probleme:
-) Angenommen, Sie möchten in einer Entwicklungsumgebung SMS-Nachrichten speichern, die an eine Textdatei gesendet wurden, anstatt das Gateway SMS zu verwenden. Am Ende ändern wir die konkrete Implementierung von (SMSService) mit einer anderen Implementierung. Wir verlieren an Flexibilität und müssen den Code in diesem Fall umschreiben.
-) Wir mischen die Zuständigkeiten der Klassen, unser (UIHandler) sollte nie über die konkrete Implementierung von (SMSService) Bescheid wissen, dies sollte außerhalb der Klassen mit Hilfe von „Schnittstellen“ erfolgen. Wenn dies implementiert ist, haben wir die Möglichkeit, das Verhalten des Systems zu ändern, indem Sie den verwendeten (SMSService) mit einem anderen Mock-Dienst austauschen, der dieselbe Schnittstelle implementiert. Dieser Dienst speichert SMS in einer Textdatei, anstatt sie an mobileNumber zu senden.

Um die oben genannten Probleme zu beheben, verwenden wir Interfaces, die von unserem (SMSService) und dem neuen (MockSMSService) implementiert werden. Grundsätzlich wird die neue Schnittstelle (ISMSService) das gleiche Verhalten beider Dienste offenlegen wie der folgende Code:

public interface ISMSService
{
    void SendSMS(string phoneNumber, string body);
}

Dann ändern wir unsere (SMSService) Implementierung, um die (ISMSService) Schnittstelle zu implementieren:

public class SMSService : ISMSService
{
    public void SendSMS(string mobileNumber, string body)
    {
        SendSMSUsingGateway(mobileNumber, body);
    }

    private void SendSMSUsingGateway(string mobileNumber, string body)
    {
        /*implementation for sending SMS using gateway*/
        Console.WriteLine("Sending SMS using gateway to mobile: 
        {0}. SMS body: {1}", mobileNumber, body);
    }
}

Jetzt können wir einen neuen Mock-Up-Service (MockSMSService) mit völlig anderer Implementierung unter Verwendung derselben Schnittstelle erstellen:

public class MockSMSService :ISMSService
{
    public void SendSMS(string phoneNumber, string body)
    {
        SaveSMSToFile(phoneNumber,body);
    }

    private void SaveSMSToFile(string mobileNumber, string body)
    {
        /*implementation for saving SMS to a file*/
        Console.WriteLine("Mocking SMS using file to mobile: 
        {0}. SMS body: {1}", mobileNumber, body);
    }
}

An dieser Stelle können wir den Code in (UIHandler) ändern, um die konkrete Implementierung des Dienstes (MockSMSService) wie folgt zu verwenden:

public class UIHandler
{
    public void SendConfirmationMsg(string mobileNumber)
    {
        ISMSService _SMSService = new MockSMSService();
        _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
    }
}

Wir haben eine Menge Flexibilität erreicht und die Trennung der Bedenken in unserem Code implementiert. Dennoch müssen wir die Code-Basis ändern, um zwischen den beiden SMS -Diensten wechseln zu können. Also müssen wirDependency Injectionimplementieren.

Um dies zu erreichen, müssen wir eine Änderung an unserem (UIHandler) -Klassenkonstruktor implementieren, um die Abhängigkeit durchzuleiten. Dadurch kann der Code, der den (UIHandler) verwendet, bestimmen, welche konkrete Implementierung von (ISMSService) verwendet wird:

public class UIHandler
{
    private readonly ISMSService _SMSService;

    public UIHandler(ISMSService SMSService)
    {
        _SMSService = SMSService;
    }

    public void SendConfirmationMsg(string mobileNumber)
    {
        _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
    }
}

Nun ist das UI-Formular, das mit class (UIHandler) sprechen soll, dafür verantwortlich, welche Implementierung der Schnittstelle (ISMSService) zu verbrauchen ist. Das heißt, wir haben das Steuerelement invertiert, der (UIHandler) ist nicht mehr dafür verantwortlich, welche Implementierung zu verwenden ist, der aufrufende Code entscheidet. Wir haben das PrinzipInversion of Controlimplementiert, bei dem DI ein Typ davon ist.

Der Formularcode der Benutzeroberfläche lautet wie folgt:

class Program
{
    static void Main(string[] args)
    {
        ISMSService _SMSService = new MockSMSService(); // dependency

        UIHandler _UIHandler = new UIHandler(_SMSService);
        _UIHandler.SendConfirmationMsg("96279544480");

        Console.ReadLine();
    }
}
5
JerryGoyal

Aber die Frühlingsdokumentation sagt, dass sie gleich sind.

http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction

In der ersten Zeile wird "IoC auch als Abhängigkeitsinjektion (DI)" bezeichnet.

5
user3386493

Inversion of Control ist ein Design-Paradigma mit dem Ziel, den anvisierten Komponenten Ihrer Anwendung mehr Kontrolle zu geben, denjenigen, die die Arbeit erledigen.
Abhängigkeitsinjektion ist ein Muster, das zum Erstellen von Instanzen von Objekten verwendet wird, auf die andere Objekte angewiesen sind, ohne zur Kompilierzeit zu wissen, welche Klasse zur Bereitstellung dieser Funktionalität verwendet wird.

Es gibt verschiedene grundlegende Techniken zum Implementieren der Inversion der Kontrolle. Diese sind:

  • Verwenden eines Fabrikmusters
  • Verwenden eines Service Locator-Musters
  • Verwendung einer Abhängigkeitseinspritzung eines der folgenden Typen:

    1). Eine Konstruktorinjektion
    2). Eine Setterinjektion
    3). Eine Schnittstelleninjektion
4
Saurabh

Inversion of Control ist ein generisches Konstruktionsprinzip der Softwarearchitektur, mit dessen Hilfe wiederverwendbare, modulare Software-Frameworks erstellt werden können, die einfach zu warten sind.

Es ist ein Konstruktionsprinzip, bei dem der Kontrollfluss von der generisch geschriebenen Bibliothek oder dem wiederverwendbaren Code "empfangen" wird.

Um es besser zu verstehen, wollen wir sehen, wie wir früher in der Codierung programmiert haben. In prozeduralen/traditionellen Sprachen steuert die Geschäftslogik im Allgemeinen den Fluss der Anwendung und "ruft" den generischen oder wiederverwendbaren Code/die generierten Funktionen auf. In einer einfachen Konsolenanwendung wird mein Steuerungsfluss beispielsweise durch die Anweisungen meines Programms gesteuert, die die Aufrufe einiger allgemein wiederverwendbarer Funktionen enthalten können.

print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);

//More print and scan statements
<Do Something Interesting>

//Call a Library function to find the age (common code)
print Age

Im Gegensatz dazu sind die Frameworks mit IoC der wiederverwendbare Code, der die Geschäftslogik "aufruft".

In einem Windows-basierten System steht beispielsweise bereits ein Framework zur Verfügung, um Benutzeroberflächenelemente wie Schaltflächen, Menüs, Fenster und Dialogfelder zu erstellen. Wenn ich die Geschäftslogik meiner Anwendung schreibe, würden die Ereignisse des Frameworks meinen Geschäftslogikcode aufrufen (wenn ein Ereignis ausgelöst wird) und NICHT das Gegenteil. 

Obwohl der Code des Frameworks meine Geschäftslogik nicht kennt, kann er trotzdem meinen Code aufrufen. Dies wird durch Ereignisse/Delegierte, Rückrufe usw. erreicht. Hier wird die Flusssteuerung "invertiert".

Anstatt den Kontrollfluss für statisch gebundene Objekte zu beeinflussen, hängt der Fluss also vom Gesamtobjektgraph und den Beziehungen zwischen verschiedenen Objekten ab.

Dependency Injection ist ein Entwurfsmuster, das das IoC-Prinzip zum Auflösen von Abhängigkeiten von Objekten implementiert.

Einfacher ausgedrückt: Wenn Sie versuchen, Code zu schreiben, werden Sie verschiedene Klassen erstellen und verwenden. Eine Klasse (Klasse A) kann andere Klassen (Klasse B und/oder D) verwenden. Klasse B und D sind also Abhängigkeiten von Klasse A.

Eine einfache Analogie wird ein Klassenauto sein. Ein Auto kann von anderen Klassen wie Engine, Reifen und mehr abhängen.

Dependency Injection legt nahe, dass anstelle der abhängigen Klassen (hier Class Car) ihre Abhängigkeiten (Class Engine und Tire) erstellt werden, die Klasse in die konkrete Instanz der Abhängigkeit eingefügt werden soll.

Lasst uns mit einem praktischen Beispiel verstehen. Bedenken Sie, dass Sie Ihren eigenen TextEditor schreiben. Unter anderem können Sie über eine Rechtschreibprüfung verfügen, die dem Benutzer die Möglichkeit bietet, die Tippfehler in seinem Text zu überprüfen. Eine einfache Implementierung eines solchen Codes kann sein:

Class TextEditor
{

    //Lot of rocket science to create the Editor goes here

    EnglishSpellChecker objSpellCheck;
    String text;

    public void TextEditor()

    {   

        objSpellCheck = new EnglishSpellChecker();

    }

    public ArrayList <typos> CheckSpellings()
    {

        //return Typos;

    }

}

Auf den ersten Blick sieht alles rosig aus. Der Benutzer schreibt einen Text. Der Entwickler erfasst den Text, ruft die CheckSpellings-Funktion auf und sucht nach einer Liste von Typos, die er dem Benutzer anzeigt.

Alles scheint gut zu funktionieren, bis ein Benutzer anfängt, Französisch im Editor zu schreiben. 

Um mehr Sprachen zu unterstützen, benötigen wir mehr Rechtschreibprüfung. Wahrscheinlich Französisch, Deutsch, Spanisch usw. 

Hier haben wir einen eng gekoppelten Code erstellt, wobei "English" SpellChecker eng mit unserer TextEditor-Klasse gekoppelt ist. Dies bedeutet, dass unsere TextEditor-Klasse vom EnglishSpellChecker abhängig ist, oder anders ausgedrückt: EnglishSpellCheker ist die Abhängigkeit von TextEditor. Wir müssen diese Abhängigkeit beseitigen. Außerdem benötigt unser Texteditor eine Möglichkeit, den konkreten Bezug einer Rechtschreibprüfung auf der Grundlage des Ermessens des Entwicklers zur Laufzeit zu halten. 

Wie wir in der Einführung von DI gesehen haben, legt es nahe, dass der Klasse ihre Abhängigkeiten hinzugefügt werden sollten. Es sollte also die Aufgabe des aufrufenden Codes sein, alle Abhängigkeiten in die aufgerufene Klasse/den Code einzugeben. So können wir unseren Code wie neu strukturieren

interface ISpellChecker
{

    Arraylist<typos> CheckSpelling(string Text);

}

Class EnglishSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}



Class FrenchSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}

In unserem Beispiel sollte die TextEditor-Klasse die konkrete Instanz des Typs ISpellChecker erhalten.

Jetzt kann die Abhängigkeit in Konstruktor, eine öffentliche Eigenschaft oder eine Methode eingefügt werden.

Versuchen wir, unsere Klasse mit Constructor DI zu ändern. Die geänderte TextEditor-Klasse sieht etwa so aus:

Class TextEditor

{

    ISpellChecker objSpellChecker;

    string Text;



    public void TextEditor(ISpellChecker objSC)

    {

        objSpellChecker = objSC;

    }



    public ArrayList <typos> CheckSpellings()

    {

        return objSpellChecker.CheckSpelling();

    }

}

Damit der aufrufende Code beim Erstellen des Texteditors den entsprechenden SpellChecker-Typ in die Instanz des TextEditor einfügen kann.

Sie können den vollständigen Artikel lesen hier

2
Amrit

IOC (Inversion Of Control): Die Steuerung des Containers zum Abrufen der Instanz des Objekts wird Inversion of Control genannt. Es bedeutet, dass Sie stattdessen Objekt erstellen, indem Sie new operator verwenden, damit der Container das für Sie erledigt.

DI (Dependency Injection): Das Übergeben der erforderlichen Parameter (Eigenschaften) von XML an ein Objekt (in POJO CLASS) wird als Dependency Injection bezeichnet.

2

IOC gibt an, dass externe Klassen, die die Klassen einer Anwendung verwalten, und externe Klassen bedeuten, dass ein Container die Abhängigkeit zwischen den Anwendungsklassen verwaltet. Das Grundkonzept von IOC ist, dass der Programmierer keine Objekte erstellen muss, sondern beschreibt, wie sie erstellt werden sollen.

Die Hauptaufgaben des IoC-Containers sind: Instanziieren der Anwendungsklasse. um das Objekt zu konfigurieren. die Abhängigkeiten zwischen den Objekten zu montieren.

DI ist der Prozess zum Bereitstellen der Abhängigkeiten eines Objekts zur Laufzeit mithilfe von Setter-Injection oder Konstruktor-Injection.

2
Kunal

DI und IOC sind zwei Designmuster, die sich hauptsächlich auf die Bereitstellung von lose Kopplung zwischen Komponenten oder einfach auf eine Art und Weise konzentrieren, in der wir die herkömmliche Abhängigkeit entkoppeln Beziehungen zwischen Objekten, so dass die Objekte nicht eng aneinander liegen.

Mit folgenden Beispielen versuche ich, beide Konzepte zu erläutern.

Zuvor schreiben wir Code so

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

Mit der Abhängigkeitseinspritzung sorgt der Abhängigkeitseinspritzer für die Instantiierung von Objekten

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 

  dependentObject.someMethod();
}

Der obige Prozess der Übergabe der Kontrolle an andere (zum Beispiel den Container) für die Instantiierung und Injektion kann als Inversion der Kontrolle bezeichnet werden, und der Prozess, bei dem der IOC - Container die Abhängigkeit für uns injiziert, kann als Abhängigkeit bezeichnet werden Injektion.

IOC ist das Prinzip, bei dem der Steuerfluss eines Programms umgekehrt wird: Anstelle des Programmierers, der den Fluss eines Programms steuert, steuert das Programm den Fluss, indem der Aufwand für den Programmierer reduziert wird, und der Prozess vom Programm verwendet, um die Abhängigkeit zu injizieren, wird als DI bezeichnet.

Die beiden Konzepte arbeiten zusammen und geben uns die Möglichkeit, viel flexibleren, wiederverwendbaren und gekapselten Code zu schreiben, der sie zu wichtigen Konzepten für objektorientierte Lösungen macht.

Empfehle auch zu lesen.

Was ist Abhängigkeitsinjektion?

Sie können auch eine meiner ähnlichen Antworten hier überprüfen

Unterschied zwischen Inversion der Kontrolle und Abhängigkeitsinjektion

2
Samuel J Mathew

IOC (Inversion of Control) ist im Wesentlichen ein Entwurfsmusterkonzept, bei dem Abhängigkeiten entfernt und von der Entkopplung des Flusses abgeglichen werden, sodass der Fluss/die andere Entität die Bereitstellung von Abhängigkeiten verwaltet. Es folgt eigentlich der Hollywood-Chef: "Rufen Sie uns nicht an, wir rufen Sie an". Fasse also die Unterschiede zusammen. 

Umkehrung der Kontrolle: - Es ist ein allgemeiner Begriff, um die Abhängigkeiten zu entkoppeln und ihre Bereitstellung zu delegieren. Dies kann auf verschiedene Arten implementiert werden (Ereignisse, Delegierte usw.).

Abhängigkeitsinjektion: - DI ist ein Subtyp von IOC und wird durch Konstruktorinjektion, Setterinjektion oder Methodeninjektion implementiert.

Der folgende Artikel beschreibt dies sehr ordentlich.

https://www.codeproject.com/Articles/592372/Dependency-Injection-DI-vs-Inversion-of-Control-IO

2
supernova

// ICO, DI, vor 10 Jahren, das war der Weg:

public class  AuditDAOImpl implements Audit{

    //dependency
    AuditDAO auditDAO = null;
        //Control of the AuditDAO is with AuditDAOImpl because its creating the object
    public AuditDAOImpl () {
        this.auditDAO = new AuditDAO ();
    }
}

Jetzt mit Spring 3,4 oder neuestem ist es unten

public class  AuditDAOImpl implements Audit{

    //dependency

     //Now control is shifted to Spring. Container find the object and provide it. 
    @Autowired
    AuditDAO auditDAO = null;

}

Insgesamt ist die Steuerung vom alten Konzept des gekoppelten Codes zu den Frameworks wie Spring invertiert, die das Objekt verfügbar machen. Das ist also IOC soweit ich weiß und Abhängigkeitsinjektion, wie Sie wissen, wenn wir das abhängige Objekt mithilfe von Konstruktor oder Setzern in ein anderes Objekt injizieren. Inject bedeutet im Grunde, es als Argument weiterzugeben. Im Frühjahr haben wir eine auf XML und Annotationen basierende Konfiguration, in der wir das Bean-Objekt definieren und das abhängige Objekt mit dem Constructor- oder Setter-Injektionsstil übergeben.

0
Vaibs

Das IoC-Konzept war ursprünglich in der Ära der prozeduralen Programmierung zu hören. Daher sprach IoC aus einem historischen Kontext über die Inversion von der Eigentumsrechte an Kontrolle - Fluss dh wem gehört die Verantwortung, die Funktionen in der gewünschten Reihenfolge aufzurufen - ob es die Funktionen selbst sind oder ob Sie sie in eine externe Entität umkehren sollten.

Als jedoch der OOP auftauchte, begannen die Leute, über IoC im OOP Kontext zu sprechen, in dem sich Anwendungen neben dem Kontrollfluss auch mit der Objekterstellung und ihren Beziehungen befassen. Solche Anwendungen wollten das Eigentum an der Objekterstellung invertieren (anstatt den Kontrollfluss) und erforderten einen Container, der für die Objekterstellung, den Objektlebenszyklus und die einspeisenden Abhängigkeiten der Objekte verantwortlich ist Anwendungsobjekte, wodurch Anwendungsobjekte davon abgehalten werden, andere konkrete Objekte zu erstellen.

In diesem Sinne ist DI nicht dasselbe wie Io C, da es nicht um Kontrollfluss geht, sondern um eine Art von Io * , dh Inversion des Eigentums an der Objekterstellung.

Was ist falsch an meiner Art, DI und IoC zu erklären?

0
Fahim Farook

Zu dieser Frage würde ich sagen, dass das Wiki bereits detaillierte und leicht verständliche Erklärungen geliefert hat. Ich werde hier nur das Wichtigste zitieren.

Implementierung von IoC

Bei der objektorientierten Programmierung gibt es mehrere grundlegende Techniken, um die Inversion der Steuerung zu implementieren. Diese sind:

  1. Verwenden eines Service-Locator-Musters Verwenden von Abhängigkeitsinjektion, zum Beispiel Konstruktorinjektion Parameterinjektion Setter-Injektion Schnittstelleninjektion;
  2. Verwenden einer kontextualisierten Suche;
  3. Unter Verwendung des Schablonenmethoden-Entwurfsmusters;
  4. Mit Strategie-Design-Muster

Wie für Abhängigkeitsinjektion

die Abhängigkeitsinjektion ist eine Technik, bei der ein Objekt (oder eine statische Methode) die Abhängigkeiten eines anderen Objekts liefert. Eine Abhängigkeit ist ein Objekt, das verwendet werden kann (ein Dienst). Eine Injection ist die Weitergabe einer Abhängigkeit an ein abhängiges Objekt (einen Client), das diese verwenden würde.

0
Hearen

Beginnen wir mit D von SOLID und werfen Sie einen Blick auf DI und IoC aus Scott Milletts Buch "Professional ASP.NET Design Patterns":

Prinzip der Inversion der Abhängigkeit (DIP)

BeimDIPgeht es darum, Ihre Klassen von Beton zu isolieren Implementierungen und deren Verwendung hängen von abstrakten Klassen oder .__ ab. Schnittstellen. Es fördert eher das Mantra der Kodierung für ein Interface als eine Implementierung, die die Flexibilität innerhalb eines Systems um .__ erhöht. Sicherstellen, dass Sie nicht eng an eine Implementierung gekoppelt sind.

Abhängigkeitsinjektion (DI) und Inversion der Kontrolle (IoC)

Mit dem DIP eng verbunden sind das DI-Prinzip und das IoC-Prinzip.DIist der Vorgang des Bereitstellens einer niedrigen oder abhängigen Klasse über eine Konstruktor, Methode oder Eigenschaft. In Verbindung mit DI werden diese abhängige Klassen können in Schnittstellen oder abstrakte Klassen umgewandelt werden das führt zu locker gekoppelten Systemen, die in hohem Maße überprüfbar sind und einfach zu ändern 

In IoC wird der Steuerungsfluss eines Systems umgekehrt im Vergleich zur prozeduralen Programmierung. Ein Beispiel hierfür ist ein IoC container , dessen Zweck es ist, Services in den Clientcode einzufügen ohne dass der Client-Code die konkrete Implementierung angibt . Das Steuerelement, das in diesem Fall invertiert wird, ist der Akt von Client, der den Dienst erhält.

Millett, C (2010). Professionelle ASP.NET-Entwurfsmuster. Wiley Publishing. 7-8.

0
GorkemHalulu

1) DI ist Child-> obj hängt von parent-obj ab. Das Verb hängt von Bedeutung ab. 2) IOC ist Child-> obj unter einer Plattform. wo Plattform Schule, Hochschule, Tanzunterricht sein könnte. Perform ist eine Aktivität mit unterschiedlichen Implikationen für jeden Plattformanbieter.

praktisches Beispiel: `

//DI
child.getSchool();
//IOC
child.perform()// is a stub implemented by dance-school
child.flourish()// is a stub implemented by dance-school/school/

`

-AB

0
Abhishek

Ich fand das beste Beispiel auf Dzone.com , was wirklich hilfreich ist, um die wirklichen Unterschiede zwischen IOC und DI zu verstehen 

"IoC ist, wenn jemand anderes Objekte für Sie erstellt." Statt "new" (z. B. MyCode c = new MyCode ()) in Ihren Code zu schreiben, wird das Objekt von jemand anderem erstellt. Dieses "jemand anderes" wird normalerweise als IoC-Container bezeichnet. Dies bedeutet, dass wir die Berechtigung (Kontrolle) an den Container übergeben, damit die Instanz des Objekts als Inversion der Kontrolle., .__ bezeichnet wird. bedeutet, anstatt Objekt mit dem neuen Operator zu erstellen, lassen Sie den Container das für Sie tun.

   DI(Dependency Injection):  Way of injecting properties to an object is 
   called 
  Dependency injection.
   We have three types of Dependency injection
    1)  Constructor Injection
    2)  Setter/Getter Injection
    3)  Interface Injection
   Spring will support only Constructor Injection and Setter/Getter Injection.

Den ganzen Artikel lesen IOC und Den ganzen Artikel lesen DI

0