« Tanzschule | Main | IceIceBaby »
Dienstag, Februar 02, 2010
AdamEE
Leicht ungeplant schaffe ich es doch noch zu Adam in die LOB: "Real World Java EE Patterns - Rethinking Best Practices"
Auf den ersten Blick sieht aber alles ziemlich chaotisch aus. Java Context and Dependency Injection (CDI) (JSR-299), Dependency Injection for Java (JSR-330) und EJB 3.1 definieren Dependency Injection. Managed Beans (aus JSF), CDI-Beans und EJBs verfügen über einen definierten Lebenszyklus.
Es war unterhaltsam, wenn auch etwas atemlos. Adams große Stärke ist die Besinnung auf das Einfache, Undogmatische. Nicht umsonst zeigt er die "Simplest possible EJB", eine Enterprise Bean mit gerade 5 Zeilen.
@Stateless
public class HelloService {
public String
getHello(){
return "Hello from EJB / CDI";
}
}
Er fragt, wozu man ohne Grund einfach immer ein Interface erstellt,
selbst wenn es niemals mehr als genau eine Implementierung geben wird.
Das verschmutzt nicht nur den Namensraum ("ICustomer" oder
"CustomerImpl" wenn "Customer" reichen würde) und es bringt fürs Testen
auch keine Vorteile, denn auch Klassen kann man mocken (ok, sie dürfen
nur nicht final sein).
Er fragt, warum man die Datenbank (ausser generiertem Mapping) abstrahieren muss, wenn man sie im Griff hat bzw. verwaltet? Niemand hat jemals Oracle ausgetauscht :-)
Er fragt, wozu man 5 Layer hat, wenn bei der neuen Anzeige eines Datenbank-Felds alle 5 geändert werden müssen. Adam benutzt häufig nur 1 Entität in allen Schichten.
Zum Beispiel JSF-to-EJB: Die o.g. EJB und die Verwendung in JSF:
@Stateless public class HelloService { @EJB
ClockService clockService; public String getHello(){
return "Hello from EJB / CDI: " + clockService.currentTime(); }}
<h:body><h:form><h:outputLabel
value="#{helloService.hello}"/></h:form></h:body>
Ganz allgemein schwimmt er gegen den Strom: Setzt EJB ein und progagiert Windows Vista, auch wenn er mit einem MacBook auflief, weil Lenovo ihn versetzt hat. Und es fiel auch die Frage, wer ausser Adam überhaupt noch EJB macht :-)?
Aber die gute Nachricht ist, dass es mit der neue EJB-Spec ein bisschen egal geworden ist, ob Spring oder EJB: Annotations sind z.T. identisch, Konvention over Konfiguration sorgt in beiden Umgebungen für schlanken Code. Konfiguration mit XML ist in EJB tot, eine leere beans.xml ist das jämmerliche Relikt, in Spring kommt man mittlerweile auch mit viel weniger applicationContext.xml aus.
SOA ist bei Managern beliebt, in der Praxis aber nicht so einfach bzw.
leichtgewichtig: Datentypen konvertieren zwischen .NET und Java ist
hakelig. Wenn man es ROA nennt (Resource oriented architecture) und REST
over HTTP macht, kommt man weiter: String/JSON läßt sich gut
konvertieren.
Ein vergnüglicher Abend, der Herdentrieb und Hypes kritisch beleuchtet und die scheinbar chaotische und komplexe Welt der Enterprise Anwendung ein wenig heller macht.