IoC / Dependency Injection - bitte erläutern Sie Code versus XML

8

Ich verstehe im Grunde, wie IoC-Frameworks funktionieren, aber eine Sache, die ich nicht ganz verstehe, ist, wie Code-basierte Konfiguration funktionieren soll. Mit XML verstehe ich, wie Sie einer bereitgestellten Anwendung eine neue Assembly hinzufügen und dann die Konfiguration in XML ändern können, um sie zu integrieren. Wenn die Anwendung bereits bereitgestellt ist (d. H. In irgendeiner Form kompiliert wurde), wie können dann Codeänderungen ohne Neukompilierung vorgenommen werden? Oder ist das, was Leute tun, nur config in Code ändern und neu kompilieren?

    
Steve Macdonald 24.03.2010, 23:57
quelle

4 Antworten

13

Hot-Swapping-Abhängigkeiten sind nicht das einzige Ziel der Verwendung eines DI-Containers.

Dependency Injection (DI) ist ein Prinzip, das uns bei der Entwicklung von losem Code hilft. Lose Kopplung bedeutet nur, dass wir Verbraucher und Service unabhängig voneinander variieren können. Wie wir dies erreichen, wird auf dieser Ebene nicht angesprochen.

DI-Container sind Frameworks, die die Verwendung von Kabelabhängigkeiten unterstützen. Sie sind mehr oder weniger nur Dienstprogrammbibliotheken, die uns helfen, DI-Muster anzuwenden. Nochmals, wie wir einen Container konfigurieren, steht senkrecht dazu, wie wir diese Abhängigkeiten verbrauchen.

XML-Konfigurationen ermöglicht es uns, die Containerkonfiguration ohne Neukompilierung zu ändern. Code als Konfiguration nicht.

Das Austauschen von Abhängigkeiten ohne Neukompilierung ist jedoch normalerweise nur für eine kleine Teilmenge Ihres gesamten lose gekoppelten Codes relevant. Im übrigen ist ein konventionsbasierter Ansatz viel effektiver, weil er tendenziell weniger spröde ist. Siehe hier für weitere Informationen.

    
Mark Seemann 25.03.2010, 08:23
quelle
2

Die IoC- und Dep-Injektion kann Änderungen ohne Neukompilierung zulassen (abhängig von den verwendeten Tools), erfordert sie aber nicht. Bei der Verwendung von Code zum Konfigurieren geht es um die Konfiguration des Containers und nicht um Änderungen nach der Bereitstellung. Ja, wenn Sie die Änderung im Code vornehmen, müssen Sie normalerweise neu kompilieren.

    
Philip Rieck 24.03.2010 23:59
quelle
1

Änderung des Codes ohne Neukompilierung, ist NICHT möglich. Änderung der Konfiguration in Web.Config gespeichert, ohne den App Pool neu zu laden, ist NICHT möglich. Sie können jedoch das folgende Szenario verwenden, in dem Sie den Code nicht erneut kompilieren oder den App Pool recyceln müssen.
 1. Speichern Sie Ihre Mappings in einer externen Konfigurationsdatei. (XML ist in Ordnung)
 2. Schreiben Sie eine Funktion, die die Mappings aus der externen Datei lädt     dein Behälter.
 3. Expose eine Funktion, die die Zuordnungen neu lädt.
 4. Wenn Sie die Zuordnungen erneut laden möchten, rufen Sie einfach das Exposed auf     Methode und du bist gut zu gehen :)

Sie können die Zuordnungen auch auf einem SQL-Server oder an einem anderen Ort speichern. (Laden Sie sie einfach in das erforderliche Format, damit der Container sie verarbeiten kann.)

    
Sunny R Gupta 03.01.2013 04:42
quelle
0

Nur weil ein DI-Container Code zur Konfiguration verwendet, bedeutet dies nicht, dass keine Konfiguration ohne Neukompilierung geändert werden kann. Es erfordert, dass Sie genau darüber nachdenken, was Sie auf diese Weise konfigurieren möchten und wie Sie diese Konfiguration ändern können (z. B. über eine Eigenschaftendatei).

    
ColinD 25.03.2010 01:45
quelle