Deutsches Java Blog von Jörg Herbst

Wie wohl bei den meisten Java Programmierer hat JavaScript auch bei mir einen eher zweifelhaften Ruf. Zu oft habe ich in der Vergangenheit JavaScript gesehen, der unverständlich, schwer wartbar und oftmals auch Browserabhängig war.
Seit einiger Zeit aber verbessert sich die Situation. Zum einen scheinen die Browser kompatibeller zu werden, zum anderen setzten sich Stück für Stück fertige Bibliotheken wie dojo, scriptaculous oder jquery durch. Mir persönlich gefällt dabei letzter am besten, da sie keine fertigen Komponenten anbietet, sondern quasi eine API bietet, die das JavaScript programmieren erleichtert.
Basis sind hierzu CSS Selektoren, mit denen man gezielt einelnen Element des Dom Baumes ansprechen kann. Dadurch kann ich mit einem Ausdruck wie #navigation die Navigation erreichen, oder mit .article alle Elemente mit der Klasse article Ansprechen. Dadurch muss ich mich überhaupt nicht mehr darum kümmern, wie die entsprechende Elemente ermittelt werden sondern muss mir nur überlegen was ich ansprechen möchte.
Damit komme ich mit JavaScript zum einem deklarativen Programmierstil, ähnlich wie in SQL für relationale Datenbanken oder in XPath für XML Elemente. Ich beschränke mich darauf zu sagen was ich womit machen möchte und überlasse das wie der Engine.

Bei der Ajaxschmiede gibt es ein paar gute einführende Beispiele.

Zur Zeit sammle zum ersten mal größete Erfahrung mit dem Einsatz von iBatis. Bis vor einiger Zeit war für mich eigentlich Hibernate das Mittel der Wahl, wenn es um einen O/R Mapper ging. Mit der Einführung von EJB 3.0 war auch ein klarer Migrationsweg erkennbar, dennoch ist mein Zwischenfazit relativ positiv.

• Entwicker tun sich leichter mit SQL Statements als mit vermeintlich einfacherern (?) HQL Statements
• Man kann gezielter Statements aufrufen, es werden nur wirklich benötigte Daten geladen, was zu geringeren Resourcen verbrauch führt
• Ich kann gezielt (pro Anwendungsfall) die zu ladenden abhängigen Objekte (Relationships) definieren
• Die (erzwungene) Trennung von SQL und Java Code erhöht die Lesbarkeit

Viele dieser Sachen (gezielte Definitions von fetch clauses, Auslagern der HQL Statements) lassen sich zwar auch mit Hibernate realisieren, aber die Lernkurve bei iBatis ist deutlich flacher.

Trotzdem ist auch iBatis nicht perfekt, folgende Nachteile haben sich rauskristallisiert:

• Es muss deutlich mehr Code geschrieben werden
• Die Entwicklung muss Datenbank getrieben erfolgen, darunter leider das Objektmodell
• Änderungen am Datenmodell sind deutlich umständlicher als bei Hibernate