EJB 3-Anmerkungen in vollem Umfang.

Bis jetzt bin ich noch nicht dazu gekommen, EJB3 in einem echten Projekt zu verwenden. Wir haben bereits Spring und Hibernate, also sehe ich keinen Sinn darin. Natürlich ist auch die ganze EJB1 und EJB2 Sache noch in meinem Hinterkopf. Auf der QCon London habe ich an der EJB 3.0-Sitzung mit LindaDeMichel teilgenommen und das schien mir ein guter Zeitpunkt zu sein, um zu sehen, ob ich meine Sichtweise auf EJBs ändern muss. Wie Sie wahrscheinlich bereits wissen, besteht das Gute an EJB3 darin, dass Sie Ihre EJBs jetzt ohne einen laufenden Container testen können und keine obskuren Schnittstellen und Klassen mehr erweitern oder implementieren müssen. Aber in diesem Blog geht es nicht um die Funktionen von EJB3, sondern um die Verwendung von Annotationen, oder sollte ich sagen, den Missbrauch....

Das erste, das auftaucht, ist: @PersistenceContext (es gab viele, aber es ist unmöglich, sich an alle zu erinnern) Sie können zum Beispiel in einer EJB sagen:

@PersistenceContext EntityManager entityManager

Es handelt sich also tatsächlich um den EntityManager.... und nicht um einen PersistenceContext. Warum wird er dann @PersistenceContext genannt? In der Javadoc von PersistenceContext heißt es: "Drückt eine Abhängigkeit von einem EntityManager Persistenzkontext aus." Das wirft nicht gerade ein gutes Licht auf Sie, oder? Okay, fahren Sie mit der nächsten Annotation fort: @EJB. Nehmen wir an, Sie haben eine Klasse AccountService, die einen Verweis auf die CustomerBean benötigt, die zufällig eine EJB ist. Die CustomerBean wird wie folgt deklariert:

@Stateless public class CustomerBean implements Customer.

Nun gut, ich möchte, dass es sich um eine EJB handelt, und bei der Verwendung von Annotationen ist dies der richtige Weg. @Stateless ist also für eine EJB, aber wofür wird @EJB verwendet, könnte man meinen? Um diese Frage zu beantworten, werfen wir einen Blick auf den AccountService:

public class AccountService {
  @EJB Kunde Kunde.
}

@EJB??? Da ist es! Aber warum dort? Es ist mir egal, dass der Kunde eine EJB ist, ich will nur, dass er injiziert wird. Jetzt ist einer der Hauptgründe für die Verwendung von Schnittstellen weg: mein AcccountServive kennt Implementierungsdetails über die CustomerBean, nämlich dass sie eine EJB ist. Ein allgemeineres Problem bei der Verwendung dieser Annotationen ist, dass meine Klassen nun von JEE abhängig sind, um kompiliert werden zu können, da die Annotationen in der JEE API und nicht in der JSE enthalten sind. Dies ist auch einer der Punkte, über die Vincent gesprochen hat, als er Annotationen und POJOs miteinander vermischte. Die nächste Annotation (oder eigentlich eine Eigenschaft einer Annotation), die mich die Stirn runzeln lässt, ist die Eigenschaft mappedBy des @OneToMany. Werfen Sie einen Blick darauf:

@Entity public class Order {
  @OneToMany(mappedBy="Bestellung")
  protected Set items = new HashSet();
}

Das "mappedBy = Ordnung" fühlt sich so unnatürlich an. Zuerst dachte ich: "Natürlich ist es von Order gemappt, ich bin in der verdammten Order-Klasse". Aber dann, nachdem ich die Javadoc gelesen hatte, kam ich zu dem Schluss, dass dies tatsächlich bedeutet, dass die Eigenschaft order in der Klasse Item diese Beziehung besitzt. Aber warum muss ich dies in der Klasse Order deklarieren? Ist es für die Klasse Order wichtig, dies zu wissen? Ich denke nicht. Ich würde sagen, dass dies in die Item-Klasse gehört und insbesondere in die Nähe der order-Eigenschaft. Ich kann mit dem Rest der Anmerkungen weitermachen, aber ich habe genug. Ja, EJB3 ist viel besser als die Vorgängerversionen, aber wer hat sich die Annotationen ausgedacht? Ist es wirklich so schwierig, sinnvolle Anmerkungen zu erstellen?