Neue Ausgabe der Interface21 News
Von der Interface21-News-Mailing-Liste gibt es
hier eine neue Ausgabe. Wer immer auf dem aktuellen Stand bleiben will, kann sich
hier eintragen.
Gartner Group: Interface21 ist ein "Cool Vendor"
Interface21 ist laut den Analysten von der Gartner Group ein "Cool Vendor". Dabei wird nicht nur das Technologie-Portfolio bewertet, sondern auch das Geschäftsmodell, mehr findet sich
hier.
Noch ein Nachsatz zu Dependency Injection...
Falls es im letzten Eintrag untergegangen sein sollte: Spring ist mehr als nur Dependency Injection. Es bietet eine allgemeine universelle Plattform für die Implementierung von Java-Anwendungen. Man denke nur an die Vereinheitlichung der verschiedenen Transaktions-APIs und der Exceptions der verschiedenen Persistenz-Frameworks, die deutliche Vereinfachung bei der Benutzung der verschiedenen APIs usw.
Spring führt außerdem durchgehende Konzepte sein, die sonst in Java oft fehlen, weil die einzelnen APIs unabhängig voneinder implentiert und standardisiert werden. Dazu gehören zum Beispiel die Templates, die mittlerweile für sehr viele APIs unterstützt werden.
Die klar abzusehende Konsequenz ist, dass Spring zu einer vollwertigen Plattform wird, die für immer mehr Bereiche anwendbar ist. Das Fundament für diese Plattform wird durch bildet neben Spring Core auch Spring Web Flow, Spring Web Services, Spring Security (Acegi) usw. Dependency Injection ist eben nur
ein Feature von Spring (wenn auch ein sehr wichtiges).
Und noch ein anderer Hinweis: Das Thema "Refactorings gehen mit Spring nur für die Klassennamen" hat sich zumindest für Eclipse erledigt:
Spring IDE 2.0M3 bietet hier umfangreiche Unterstützung. Eine sehr gute Sache - mein Dank gilt dem Spring-IDE-Team für dieses neue Feature! Auf
springframework.org gab es dazu auch schon ein umfangreiches Posting, neu ist auch der Spring-Web-Flow-Support.
Dependency Injection
Es gibt immer noch eine große Anzahl Leute, die Spring wegen der XML-Konfiguration für keine gute Idee halten. Dazu kann man als erstes anmerken, dass Spring neben der XML-Konfiguration auch andere Features bietet - zum Beispiel die Integration der verschiedenen Frameworks und eine AOP-Implementierung. Spring=XML ist also schon auf der Ebene nicht richtig.
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.
Trainings-Termin
Die Termine für die Spring Core Trainings bei uns in nächster Zeit sind:
Das Spring-Core-Training bietet eine umfassende Einführung in Spring. Dazu gehören Dependency Injection, AOP, Persistenz mit JDBC und Hibernate, Transaktionen, Spring MVC, Spring Security Acegi, JMX und Spring Remoting.
Bis vielleicht dahin!
