Trennung EJB und Fachklassen

[fastjack]

Hallo

wie trenne ich in EJB am besten die Fachklassen (Simple Pojos) von den Beans, oder macht man das heutzutage überhaupt? Kann ich die Logik irgendwie per DI injekten?

Als Beispiel habe ich eine Bean, die z.B. eine Berechnung ausführen soll. Vom Gefühl her würde ich diese Berechnung in eine eigene Klasse auslagern und von der Bean nur auf diese Klasse delegieren. Allerdings wird in sämtlichen Beispielen im Internet oder Büchern die Logik in die Beanmethoden gesteckt.

Gruß Fastjack.

 

[maki]

??

Komische Frage...

Was verstehst du unter "Fachklassen"?

Was verstehst du unter "Bean"?
- JavaBean oder SessionBean, EntityBean, etc. pp.

Was verstehst du unter "POJOs"?
-Zumindest letzteres ist klar, POJOs sind normale Javaobjekte, die kein vorgegebenen Konventionen/Schnittstellen einzuhalten haben. JavaBeans zB. sind keine POJOs.

Wenn du "Logik" von den zugehörigen "Daten" trennst, programmierst du prozedural, wurde mal mit J2EE so von Sun propagiert.
Mit EJB3/JEE 5+ ist das flexibler, kannst immer noch Daten und Logik trennen wenn du willst, musst aber nicht.

 

[fastjack]

Okay ein simples Beispiel:

...
public class MyEJB {
    public CalculationResult doSomething(int param) {
        // Logik die ich eigentlich in eine eigene Klasse kapseln würde.
        CalculationResult result = ...
        result.add(....);
        result.foo();
        return result;
    }
}

z.B. so:

...
public class MyEJB {
    public CalculationResult doSomething(int param) {
        return new CalculationResultGenerator().calculate(param); // delegiert nur einfach weiter
    }
}
...
public class CalculationResultGenerator {
    public CalculationResult calculate(int param) {
        CalculationResult result = ...
        result.add(....);
        result.foo();
        return result;
    }
}
...
oder vielleicht etwas derart:
...
public class MyEJB {
    @Inject CalculationResultGenerator generator;
    public CalculationResult doSomething(int param) {
        return new generator.calculate(param); // delegiert nur einfach weiter
    }
}

Für wäre die Klasse "CalculationResultGenerator" so eine Art Fachklasse, die die eigentliche Logik enthält, oder nicht? In einem Workshop den ich gelesen habe wurde so eine Klasse als Simple POJO (sry, wenn das Mißverständnisse verursacht hat) dargestellt, frag mich nicht warum

Ich bin nachdem lesen etwas unsicher geworden. Trennt man die Logik nun oder nicht? Aus der Sicht der Wiederverwendbarkeit und Testbarkeit würde ich sie trennen. Ich habe im ganzen Netz und in vielen Büchern allerdings keine Trennung gefunden, deshalb meine Frage.

 

[fastjack]

der Workshop: Java EE Development without EJB - and without Spring - Part 1

edit: Es geht um EJB SessionBeans

 

[maki]

CalculationResultGenerator sheint ein POJO zu sein, zumdindest im gezeigten Teil.

SessionBeans war das Stichwort (bzw. eines davon), diese können entweder die Logik selber enthalten, oder delegieren, Daten enthalten sie nicht im eigentlichen Sinne, SFSB halten eben einen Zustand, ist nicht immer dasselbe wie "Daten" im Sinne wie Entites das machen.

Ich bin nachdem lesen etwas unsicher geworden. Trennt man die Logik nun oder nicht? Aus der Sicht der Wiederverwendbarkeit und Testbarkeit würde ich sie trennen. Ich habe im ganzen Netz und in vielen Büchern allerdings keine Trennung gefunden, deshalb meine Frage.

OOP bedeutet unter anderem: Daten & Logik die zusammengehören, landen in derselben Klasse (vereinfacht ausgedrückt).
Damit soll die Wiederverendbarkeit verbessert werden und die Struktur klarer hervorgestellt.

Vielleicht meinst du ja dass die SessionBean die aufrufe an Fachklassen welche Logik & Daten halten delegieren sollen?
Dann ein klares: Ja

Glaube du hast die falsche Präsenation gelinkt, hab auf keinen der 82 Seiten diesen Code entdecken können.

 

[fastjack]

okay, danke maki