Aber zurück zu der XML-Konfiguration: Sie ist eine mögliche Umsetzung von Dependency Injection in Spring. Als erstes sollte man also die Frage stellen, ob Dependency Injection überhaupt sinnvoll ist. Die Antwort ist aus meiner Sicht ein eindeutiges Ja. Man kann mit Dependency Injection Software leichter testen und sie auch leichter konfigurierbar machen. Sie wird auch objekt-orientierter, da die einzelnen Klassen weitgehend unabhängig voneinander werden. Außerdem wird sie flexibler. Zum Beispiel wird die Implementierung des Strategy-Pattern deutlich einfacher und wertvoller. Bei diesem Pattern lagert man einen Teil des Algorithmus in eine eigene Klasse aus. Durch Dependency Injection ist der Austausch des Algorithmus mit Hilfe einer Konfiguration recht einfach möglich.
Wenn man der Meinung ist, Dependency Injection sei gut, bleibt nur die Frage, wie man es umsetzten will. Dependency Injection ist eine Art Pattern, man kann es unterschiedlich implementieren. Eine Möglichkeit wäre, den ganzen Code für das Wiring selbst zu schreiben, was aber wenig übersichtlich ist. Ein Framework könnte alsodas Leben leichter machen kann.
Hier bietet zumindest Spring unterschiedliche Möglichkeiten:
- Es gibt Ansätze, die auf Autowiring basieren: Wenn ein Objekt von einem anderen abhängt, wird durch Namenskonvention oder Typ-Kompatibilität automatisch entschieden, welche Objekte zusammenhängen. Dadurch wird die Konfiguration einfacher, aber es ist auch mehr Magie und weniger explizite Steuerung. Für große Projekte wird es schwer, dieses Prinzip wirklich zu nutzen, da bei vielen Objekten oft nicht mehr klar ist, was genau wie zusammengestellt wird. Spring nutzt es zum Beispiel auch für Testfälle, was zur Folge hat, dass man sich sehr einfach zusätzliche Objekte aus der Konfiguration holen kann.
Man kann mit Java-Annotationen die Konfiguration vornehmen, bei Spring zum Beispiel mit Spring Java Configuration . Dadurch hat man eine Kombination aus Java-Code mit IDE-Unterstützung und Refactoring-Unterstützung, aber es ist eben Code, keine Konfiguration - man muss bei einer Änderung neu compilieren. Man kann dieses Vorgehen auch mit XML-Konfigurationen kombinieren. Wichtig ist: Es entstehen keine echten Factories, d.h. die Semantik wie z.B. für Singletons wird eingehalten, auch wenn eine Methode mehrfach aufgerufen wird. Der eigentliche Code der zusammen-injecteten Objekte ist von der Konfiguration nicht beeinflusst.
Oder man nutzt den Groovy Spring Bean Builder, der Spring mit Groovy-Mitteln konfiguriert.
Eine XML-Konfiguration hat zumindest bei Spring einen recht einfachen Sprach-Umfang und ist wirklich eine Konfiguration, kann also ohne Neu-Compilierung genutzt werden. Fehler fallen durch Tool-Support (z.B. das Spring IDE PlugIn für Eclipse) oft bereits beim Entwickeln auf. Refactoring beim Ändern von Klassennamen funktionier z.B. mit dem Feature von Eclipse, in XML-Dateien auch den fully qualified Classname ändern zu lassen. Umbenennen von Properties ist allerdings ein Problem. Modularisierung über <import> und abstrakte Bean-Definitionen ist ebenfalls möglich.
Ich glaube ein wichtiges Problem ist auch, dass XML in Java-Anwendungen oft problematisch und komplex ist. Für mich sind EJB-Deployment-Descriptoren sind zum Beispiel wirklich nicht erträglich, web.xml ist grenzwertig und auch Maven ist schwierig. Daher ist die XML-Abscheu vielleicht auch bis zu einem gewissen Maße durch diese Erfahrungen geprägt.
Spring hat nur einige wenige wirklich unbedingt notwendige XML-Ausdruckmittel: bean, property, ref, value. Das macht das manuelle Editieren sehr einfach. Für Spring 2.0 kommen Elemente aus den XML-Namespaces hinzu, die dann Konfigurationen erlauben, bei dem ein spezieller Vokabular das Leben einfacher macht.
Was bedeutet das? DI ist meiner Meinung nach eine sehr gute Idee. DI ist ein wichtiges Pattern und auch die Implementierung in Spring ist XML-unabhängig, man kann also andere Front-Ends darauf setzten (zum Beispiel auch Groovy). Persönlich finde ich die Spring-XML-Konfiguration eine gute Möglichkeit. XML abzulehnen ist nicht besonders konstruktiv - es wäre besser, sich für eine Alternative auszusprechen - und Spring bietet einige. Schließlich gilt die Spring-Maxime, den Nutzer möglichst viele Freiheiten zu geben. ¶ 10:33
