Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

Ist es richtig, dass ein DI Framework mir meine 'vorinstallierten' Dependencies direkt injected?
CoderboyPB
myCSharp.de - Member



Dabei seit:
Beiträge: 311
Herkunft: Paderborn

Themenstarter:

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

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

Hi,

ja so kann das funktionieren.

LG
private Nachricht | Beiträge des Benutzers
Palin
myCSharp.de - Member



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
mfe
myCSharp.de - Member



Dabei seit:
Beiträge: 183

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von mfe am .
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

Zitat von mfe
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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von LaTino am .
"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)
private Nachricht | Beiträge des Benutzers
mfe
myCSharp.de - Member



Dabei seit:
Beiträge: 183

beantworten | zitieren | melden

Zitat von LaTino
Zitat von mfe
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."
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

Zitat von mfe
Ä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)
private Nachricht | Beiträge des Benutzers
Peter Bucher
myCSharp.de - Experte

Avatar #jVxXe7MDBPAimxdX3em3.jpg


Dabei seit:
Beiträge: 6141
Herkunft: Zentralschweiz

beantworten | zitieren | melden

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

- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10084

beantworten | zitieren | melden

Und es lebt!!
Welcome Back
private Nachricht | Beiträge des Benutzers