J and I and Me
2005-12-30
 
Spring 2.0

Mittlerweile ist Spring 2.0 M1 erhältlich, was eine Vorrausschau auf einige wichtige Features erlaubt.

Eines ist die Möglichkeit, auch Objekte per Spring zu konfigurieren, die mit new erzeugt werden. Dazu kommt hinter den Kulissen AspectJ zum Einsatz. Bisher wurde ein Spring-Anwendung aus Diensten wie DAOs oder Geschäftsprozessen gebaut, die dann jeweils fachliche Klassen austauschen. Diese werden typischerweise nicht mit Spring verwaltet. Durch dieses neue Feature kann man zum Beispiel solche fachlichen Klassen durch Spring verwalten lassen und ihnen Referenzen z.B. auf den DAO mitgeben. Dadurch kann man dann an der fachlichen Klassen save() aufrufen, was dann an das DAO weiterdelegiert wird.

Eigentlich ist das ein schönes Feature, weil die Trennung in DAOs und Services auf der einen Seite und fachliche Klassen auf der anderen Seitet der Objektorientierung widerspricht: Man will ja eigentlich Objekte haben, an denen man Methoden aufrufen kann und nicht nur objektorientierte Datenmodellierung betreiben. Ich bin mir allerdings nicht so sicher, ob das tatsächlich ein so gutes Features ist. Denn auf diesem Weg verliert man die Möglichkeit, die fachlichen Klassen ohne die Dienste zu verwenden. Bei der Übertragung solcher Objekte zwischen Client und Server sind dann lustige Effekte zu benfürchten, weil man die Dienste kaum sinnvoll mit übertragen kann. Das ist ein wenig so wie das Hibernate Lazy Loading Problem, das auch auftritt, wenn man die Objekte dann zum Client schicken will. An sich ist die interessante Sache die, dass man durch Spring und SOA zu Service-orientierten Systemen kommt und die reine Objektorientierung nicht mehr so erstrebenswert erscheint.

Die restlichen Spring 2.0 Features sind eindeutig positiv: Die Konfiguration wird durch XML Schemas vereinfacht, so dass man Features wie AOP wesentliche einfacher handhaben kann. Das einzige Problem hier ist, dass die einzelnen Spring Beans und ihre Zusammenarbeit zum Teil nicht mehr so klar zu erkennen sind, aber das ist eher Information Hiding als ein Problem. Und man muss mehr unterschiedliche XML Schemas kennen.

Ein weiteres Feld ist die neue AspectJ Syntax. Zum einen werden Pointcuts jetzt so ausgedrückt und zum anderen kann man mit der AspectJ Syntax auch Klassen durch Annotationen zu Aspekten machen. Mir gefällt beides recht gut. Die Syntax von AspectJ ist mächtiger und vor allem kann man so später hoffentlich einmal die Spring AOP Laufzeitumgebung transparent gegen AspectJ austauschen. Das wiederum erhöht dann die Wahlfreiheit des Entwickler.

Noch eine kleine Eigenwerbung: Wenn alles so läuft, wie ich hoffe, wird mein Buch weltweit das erste Buch überhaupt sein, das Spring 2.0 behandelt... Hoffen wir also das beste! Auf jeden Fall bleibt Spring eine spannende Plattform.
 
Bookmark and Share
Comments:
Hi Eberhard !
Ich bin im Gegensatz zu Dir erst im dritten Spring-Monat ;-)
Ich mag Spring sehr aber nichtsdestotrotz bleibt IMHO die zentrale XML Konfigurationsdatei ein zweischneidiges Schwert.
Es ist möglich den Application Context aufzuteilen klar, aber:
-> Ein Editieren ohne Hilfe der IDE ist mühsam. Nix mit 'schnell mal beim Kunden vor Ort mit Notepad fixen'
-> Während des aktiven Entwickelns hat man die notwendigen XML-Attribute
und die nicht gerade kurzen Spring Packages gut im Griff - schon aus Gewohnheit; aber wenn man nach einem Jahr, vielleicht sogar mit einer 'Spring-Pause' zu Wartungsarbeiten zurückkehrt ...
-> Auch wenn die Errormessages brauchbar sind ist der Umstand nachteilig, dass Fehler erst zur Laufzeit erkannt werden. Das ist zwar in der Regel beim Startup des des Containers bzw des Applicationcontext, trotzdem deutlich später und unangenehmer als zum zeitpunkt des Kompilierens.
-> Da die Konfiguration auf Strings basiert können nette Nebeneffekte auftauchen. Gerade habe ich einige Stunden damit verbracht zu enträtseln, warum der VelocityView nicht gefunden wurde, obgleich die entsprechende jar im lib Verzeichnis lag. Des Rätsels Lösung war ein Sonderzeichen am Ende des Klassennamens, welches auch in der Fehlermeldung nicht sichtbar war.
Wenn jetzt die Konfiguration immer feingranularer wird und die Zusammenhänge zwischen den Beans schwerer zu ermitteln sind, sehe ich das, zugegebenermassen ohne praktische Erfahrung mit den Neuerungen, erstmal distanziert.

Viele Grüsse
Joachim

P.S.
Lese gerne Deinen Blog.
Keep it up - trotz Buch.
 
Zumindest einen Teil dieser Probleme löst die Spring IDE für Eclipse (http://www.springide.org/). Vervollständigung von Klassennamen und auch die Anzeige von JavaDoc-Hilfe bei den XML Dateien funktioniert. Das ist natürlich für die XML Schemas noch nicht vorhanden. Allerdings können durch die Schemas mehr Abstraktion geschaffen werden: Es geht eben nicht mehr um das Konfigurieren von Objekten, sondern dann kann man eine eigene Konfigurationssprache entwickeln. Schauen wir mal, wie sich das bewährt.

Das Spring-Motto schlechthin ist ja auch die Wahlfreiheit: Wenn man die Konfiguration gar nicht mag, muss man sie nicht verwenden (obwohl ich das komisch finden würde). Und mit Autowiring usw. kann man die Konfigurationen auch recht einfach halten.
 
Hallo Eberhard,

Autowiring ist auch ein zweischneidiges Schwert, eher für übersichtliche kleine Konfigurationen zu gebrauchen. Wenn man es nicht sehr restriktiv einschränkt, muss man da wirklich aufpassen.

Naja lassen wir uns mal überraschen.

Auch in IntellJ wird die Konfiguration angenehm unterstützt vor allem durch die class-name expansion der Idee (macht sie pauschal, aber in den class-feldern sehr praktisch.

Die Frage nach der Konfigurationssprache ist auch nicht so einfach, das wäre dann der Ansatz an dem schon viele Dinge gescheitert sind, noch eine komplexe Abstraktionsebene zur Konfiguration der Abstraktion (Container) in dem erst die eigentliche Anwendung läuft ....

Wenn das dann so aussieht, wie die programmatische Config von Spring, dann gute Nacht :)

Viele Grüße aus Dresden
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff