Suche Dependency Injection Container

[sulo]

Hi,

ich suche einen einfach zu benutzenden DI-Container? Kann da einer was empfehlen? Was nehmt Ihr da so als standalone Lösung? oder implementiert ihr euch das selbst?

Ich suche halt etwas, dass ich in eine xml-config Datei configurieren kann und was möglichst klein und einfach zu nutzen ist.

Wäre toll wenn ihr da was zu schreiben könntet.

Grüße
Sulo

 

[maki]

Google Guice! Ist auch die Referenzimplementierung vom JSR 330 (DI).
Ohne XML Dateien

Ansonsten natürlich Spring, aber selbst da sind XML mittlerweile nicht mehr Stand der Dinge.

Im JEE Umfeld (also CDI, JSR 299) ist Weld der IMHO einzige...

Änderung: JSR korrigiert...

 

[tfa]

Ein Beispiel mit Spring:
http://www.java-forum.org/blogs/tfa/27-how-dependency-injection-spring.html

Und eins mit Guice:
http://www.java-forum.org/blogs/the_29/29-dependency-code-injection-google-guice.html

 

[nillehammer]

Ich habe Erfahrungen mit Guice und mit Tapestry-IOC gesammelt. Die kann ich beide empfehlen. Allerdings ist XML-Konfiguration nicht mehr State of the Art. Die beiden genannten werden jedenfalls mit Annotationen konfiguriert.

 

[sulo]

Hat ne xml-configuration nicht den Vorteil, dass man nicht alles neu kompilieren muss? z.B. einfach eine weitere (kompilierte) Validator-Klasse in die xml-config eingetragen und man muss das Projekt nicht neu übersetzen. Oder entbehrt sich mir gerade irgendwas?

 

[nillehammer]

Ja, im Prinzip hört sich das nach ner guten Idee an. Aber in Produktivumgebungen funktioniert das nicht wirklich. Erstens fuddelt man da nicht on the fly so in Konfigdateien rum. Zweitens müsste, selbst wenn man es tut, die andere Klasse bereits mit deployt sein. Falls sie das nicht ist, muss man sowieso neu deployen. Da kann man auch neu compilieren. Und drittens hat es sich gezeigt, dass das Hantieren mit xml-Konfigurationen schnell ausartet und man die Fehler immer erst sehr spät sieht.

Mit Annotations hast du als Java-Programmierer die Konfigurationsanweisungen genau da, wo sie für Dich am bequemsten zu erreichen sind, im Java-Code. Außerdem werden Dir der größte Teil der möglichen Fehler als Compilierfehler angezeigt. Du siehst also i.d.R. schneller, wenn du was falsch gemacht hast. Annotationsbasierte Konfigurationen sind auch stabiler bei Refactorings, weil die IDEs neue Namen oder Packagestrukturen im Java-Code anpassen, in XML-Dateien aber eher nicht.

 

[maki]

Hat ne xml-configuration nicht den Vorteil, dass man nicht alles neu kompilieren muss? z.B. einfach eine weitere (kompilierte) Validator-Klasse in die xml-config eingetragen und man muss das Projekt nicht neu übersetzen. Oder entbehrt sich mir gerade irgendwas?

Nur weil das in XML Dateien liegt und nicht im Javacode, ist es trotzdem noch Code.
D.h. es muss genauso getestet werden etc. pp., und bauen inkl. packagen muss man es trotzdem noch, dadurch entfällt dieser Vorteil von "externen" (XML) Dateien wieder IME.
XML Dateien sind dann nur noch umständlicher beim editieren/refactoren.

Haben zwar vielleciht den Vorteil, dass man u.U. keine "fremd-lib imports" mehr in seinen Klassen hat.