Laden...

Ist es richtig, dass ein DI Framework mir meine 'vorinstallierten' Dependencies direkt injected?

Erstellt von CoderboyPB vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.925 Views
C
CoderboyPB Themenstarter:in
327 Beiträge seit 2008
vor 5 Jahren
Ist es richtig, dass ein DI Framework mir meine 'vorinstallierten' Dependencies direkt injected?

Die eigentliche Injection ist ja folgendes:


class Klasse
{
    IDependency d;
    
    Klasse(IDependency _d)
    {
          d=_d;
    }
}

Verstehe ich das richtig, dass ein DI Framework mir nun ermöglicht mir meine Objekte mit 'vorinstallierten' Dependencies zu definieren, und diese dann direkt instanziiert über den Container abrufen zu können ?

Habe ich das soweit in der Theorie erst mal richtig verstanden?

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

ja so kann das funktionieren.

LG

P
1.090 Beiträge seit 2011
vor 5 Jahren

Jein.

Ich denke mal mit eine DI Frameworke, meinst du einen IOC-Container. Und ich denke du meinst das richtige. Nur drückst es ein wenig unglücklich aus. Grundlegend kann man einen IOC-Container irgendwo in der Anwendung verwenden und "sagen" gibt mir mal eine Instand von X. Ist aber nicht wirklich schön.

Wenn du es richtig machst, verwendest du ihn nur einmal beim Start (z.B. Apolication Run) und er löst dir alle Abhängigkeiten der Anwendung auf (IView, IBL und IDAL usw. um es vereinfacht dazustelle). Je nach verwendeten IOC-Container, kannst du auch definieren wie die Abhängigkeiten aufgelöst werden. Z.B. wenn du deine Software um ein "Modul" erweitern willst. Reicht es teils einfach eine DLL mit passender Schnittstelle in dein Anwendungsverzeichnis zu packen und das Modul ist verfügbar.
Oder er regelt ob du immer die selbe Instanz einen Objektes (Singelton) oder immer eine neu zurück bekommst. Ein guter IOC-Conatiner kann, da echt eine Menge.

Grundlegend also eher ein bisschen von außen Betrachtet, du rufst nicht die Instanz vom IOC ab (Gut beim Start machst du es). Er löst sie für die auf.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

M
177 Beiträge seit 2009
vor 5 Jahren

IoC - Inversion of Control bedeudet, dass du die Steuerung deines Programmablauf abgibst. Du schreibst deinen Programmcode nur noch in die Schablone. Das Framework ruft, dann deinen Programcode auf. Daher auch als Hollywood Prinzip bekannt. Don't call us, we call u.

Dependecy Injection - Bei der Dependecy Injection gibt man die Objekterzeugung ab. Heutige DI Frameworks können Abhänigkeiten bei der Objekterzeugung erkennen und lösen diese in richtiger Reihenfolge und Abhänigkeit auf. Sollte z.B. die Implementierung IDependency eine Abhänigkeit auf Komponente xy haben, muss zuerst diese erzeugt werden. Erst danach kann IDependecy aufgelöst werden.

Die Begriffe gleichzusetzen ist etwas heikel.

3.003 Beiträge seit 2006
vor 5 Jahren

IoC - Inversion of Control bedeudet, dass du die Steuerung deines Programmablauf abgibst.

Äh, nein, das bedeutet es nicht. Es bedeutet, dass die konsumierende Klasse bestimmt, wie Teilaspekte des Programmablaufs, der in der/den ausführenden Klasse(n) definiert ist, implementiert sind. Die ausführenden Klassen geben die Verantwortung für die Implementierung ab. Dadurch wird der Konsument anstelle der ausführenden Klasse zum steuernden Teil - inversion of control, literally.

Der Programmablauf bleibt gleich.
Die Implementierung der Verarbeitung wird vom Konsumenten vorgegeben.

Erreichen kann man diese Umkehr durch Dependency Injection, also durch Einschießen der Implementierungen in die ausführende Klasse. Das ist nicht die einzige Methode, um IoC zu implementieren, aber die praktikabelste.

Und eine Form der Dependency Injection wäre über einen DI-Container, aber auch das ist kein Muss. Und auch mit einem DI-Container gibt man nirgendwo die Objekterzeugung ab, diese Aussage halte ich für ziemlich daneben. Das sind keine magischen Wesen, die irgendwo unabhängig vom Entwickler im Raum schweben und Gedanken lesen.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

M
177 Beiträge seit 2009
vor 5 Jahren

IoC - Inversion of Control bedeudet, dass du die Steuerung deines Programmablauf abgibst.

Äh, nein, das bedeutet es nicht. Es bedeutet, dass die konsumierende Klasse bestimmt, wie Teilaspekte des Programmablaufs, der in der/den ausführenden Klasse(n) definiert ist, implementiert sind. Die ausführenden Klassen geben die Verantwortung für die Implementierung ab. Dadurch wird der Konsument anstelle der ausführenden Klasse zum steuernden Teil - inversion of control, literally.

Äh... nein und nochmal nein. Es heißt "Statt dass die Anwendung den Kontrollfluss steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausführung bestimmter Unterprogramme an das Framework abgegeben."

3.003 Beiträge seit 2006
vor 5 Jahren

Äh... nein und nochmal nein. Es heißt "Statt dass die Anwendung den Kontrollfluss steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausführung bestimmter Unterprogramme an das Framework abgegeben."

Tja. Wirf auch mal einen Blick in die englische Wikipedia, statt die deutsche hier ohne Quellenangabe zu zitieren. Die deutsche ist hier leider ziemlich missverständlich.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

5.941 Beiträge seit 2005
vor 5 Jahren

Hallo

Umkehrung der Kontrolle für die Objektinstanziierung einer Implementation, die registriert wird. Anstelle irgendwo innerhalb der Klasse ein "new MyImplementation()" zu machen, wird dies ausserhalb vom Dependency Injection Container gemacht.
Die Instanz kommt in das Objekt von aussen, nicht die Instanz wird im Objekt das diese benötigt instanziert. So hast du keine Abhängigkeiten mehr auf Implementationen (Klassen), sondern nur noch auf Abstraktionen (meinst ein Interface oder auch eine abstrakte Klasse, selten eine konkrete Oberklasse).

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

F
10.010 Beiträge seit 2004
vor 5 Jahren

Und es lebt!!
Welcome Back