Auf Thema antworten

Hallo hyperion

Wenn ich die Snippets richtig verstanden habe sieht dein Beispiel etwa folgendermassen aus:

[ATTACH]7166[/ATTACH]

Ich würde die folgenden Dinge anschauen:

1. Naming:
   (Siehe Guidelines, Patterns, and code for end-to-end Java applications)
   Die Endung Bean wird normalerweise für SessionBeans verwendet (gemäss dem Link auch für Entity-Beans, da wird teilweise auch die Endung Entity oder ähnlich benützt).
   Transferobjekte (wie das OutcomeBean in deinem Beispiel) würde ich nicht mit Bean, sondern eher mit Dto, Vo, ... kennzeichnen (Siehe auch java - Difference between DTO, VO, POJO, JavaBeans? - Stack Overflow)
2. Einsatz der Named Queries
   Was ist der Grund für die Named Queries in der Klasse Outcome?
   Alternative wäre Code ala [code=Java]public List<Outcome> ladeAlleOutcomes() {
       Criteria criteria = getHibernateSession().createCriteria(Outcome.class);
       List<Outcome> outcomes = criteria.list();
       return outcomes;
   }[/code] Je nach Anforderungen erweitert um Restriktionen oder ähnlich:
   [code=Java]criteria.add(Restrictions.eq("category", category));[/code] Vorteil von diesem Ansatz wäre, dass du kein oder weniger hql in den Klassen hast. (Der Entscheid zu HQL oder Criteria ist eher subjektiv, Criteria geht wahrscheinlich weniger schnell kaputt).
3. In deinem Beispiel greifst du direkt aus dem Controller (Client) auf die Persistenz zu. Sobald die Applikation grösser wird, würde ich einen Service- und/oder einen Function/Logic-Layer reinziehen. Andernfalls besteht die Gefahr, dass die Applikation rasch unübersichtlich wird.
4. Aus Sicht des Unittestings würde es sich anbieten, die Mapping-Logik der Methode OutcomeEjb.addOutcome() in einen Mapper auszulagern. Dann könntest du das Mappen der Objekte unabhängig von der Persistenzanbindung testen => bessere Testbarkeit der Applikation.

Freundliche Grüsse

CptSocket