EntityBean Tutorial

[Ceene]

Hallo werte Community

Ich fange gerade an mit Beans zu arbeiten und haben die SessionBeans hinter mir. Durch ein Tutorial war das verständniss für diese Bean art recht gut zu verstehen. Nun möchte ich mit EntityBeans arbeiten, da ich nun eine Datenbank ansprechen möchte. Als Applicationserver verwende ich JBoss 4.2.2 und als Entwicklungsumgebung Eclipse 3.2.2

Ich habe schon das halbe Internet abgesucht und bin leider über kein Tutorial gestolpert, welches EntityBeans gut erklärt. Da wollte ich euch mal fragen ob ihr eventuell ein gutes Tutorial kennt oder ob mir einer ein paar Tips geben kann, wie man sich gut in das Thema einarbeiten kann.

Wäre für Hilfe sehr dankbar.

 

[J.C.]

Normalerweise sind ja SessionBeans zusammengefasste EntityBeans, also ist mir ehrlich gesagt unklar wie du SessionBeans ohne Entitäten erlernen konntest???

Wenn du über SessionBeans Objekte peristierst, dann ist das falsch. Der Client hat (oder besser gesagt sollte) nur auf SessionBeans zugreifen, sonst kann er ja direkt auf die Persistenzschicht zugreifen.

Persistier deine daten über EntityBeans und fass in deinen Sessions die EntityBeans zusammen.


Aber zu deinem Thema: keine Ahnung. (Aber wenn meine HP mal fertig ist kommst damit sicherlich weiter)

 

[bronks]

z.B. www.laliluna.de oder http://www.netbeans.org/kb/trails/java-ee.html

 

[Guest]

Normalerweise sind ja SessionBeans zusammengefasste EntityBeans, also ist mir ehrlich gesagt unklar wie du SessionBeans ohne Entitäten erlernen konntest???

Wie kommst du auf sowas? SessionBeans und EntityBeans haben zumächst mal rein gar nichts miteinander zu tun.

 

[Robin479]

Entities repräsentieren zumeinst einfache Business Objekte, die im prinzip nichts anderes machen als eine Hand voll Informationen in einem Objekt zu vereinen (Bsp: "Nutzer" hat "Name", "Alter", "Adresse", ...), ähnlich wie structs in C. Wenn solche Entities nun noch standard Accessor und Mutator Methoden besitzen um auf die Felder zuzugreifen, nennt man sie EntityBeans.

public class Entity {
    public int attribute1;
    public String attribute2;
    // ...
}

public class EntityBean {
    private int attribute1;
    private String attribute2;
    // ...

    public void setAttribute1(int value) {
        this.attribute1 = value;
    }
    public int getAttribute1() {
        return this.attribute1;
    }

    public void setAttribute2(String value) {
        this.attribute2 = value;
    }
    public String getAttribute2() {
        return this.attribute2;
    }

    // ...
}

Das hat viele Vorteile, die ich nicht alle nennen kann.

Einer der wenigen Nachteil: redundanter Code, zur Wahrung des EJB standards.

 

[maki]

Einer der wenigen Nachteil: ...

Noch ein "kleiner Nachteil": Man wirft die Prinzipien der Objektorientierung über Board und trennt Daten von Verhalten... willkommen zurück in der prozeduralen Programmierung.

 

[Guest]

Einer der wenigen Nachteil: ...

Noch ein "kleiner Nachteil": Man wirft die Prinzipien der Objektorientierung über Board und trennt Daten von Verhalten... willkommen zurück in der prozeduralen Programmierung.

Wenn man OOP als Religion betrachtet, dann hast du recht.

 

[maki]

Wenn man OOP als Religion betrachtet, dann hast du recht.

Naja, als Religion muss man weder die OOP noch EJBs ansehen

OOP hat nunmal erhebliche Vorteile gegenüber dem prozeduralen Ansatz.
EJBs fördern die prozedurale Programmierung, bieten dafür aber andere Vorteile, zumindest einen:
Skalierbarkeit durch Clustering.

Aber mal ehrlich, welches Projekt braucht das schon?

Denn alles andere kann man auch ohne EJBs erreichen, oft einfacher.
Alles andere? Nein, EJBs selbst bekommt man nur mit EJBs

 

[karatekid]

bieten dafür aber andere Vorteile, zumindest einen:
Skalierbarkeit durch Clustering.

Aber mal ehrlich, welches Projekt braucht das schon?

z.B. eine Applikation die 800.000 Dokumente zu 2-5 Seiten über Nacht in ca. 4h verarbeiten muss, damit tagsüber über 30.000 Mitarbeiter diese weiterverarbeiten können ? :wink:

Man muss ja kein Freund von EJBs sein, aber ich verstehe diese abwertende Haltung "Ich mache alles ohne EJB... viel einfacher, viel schöner... " nicht. ???:L Wenn es nicht gebraucht würde, würde sich die Technologie nicht am Markt halten. Ich kenne zumindest einige Projekte, in denen man sich für die falsche Technologie entschieden hatte. Der Aufwand das dann clustersave umzusetzten ist heftig.

Und ob die Lösungen mit anderen Technologien immer einfacher, schneller, effizienter sind, möchte ich doch mal stark bezweifeln.

 

[maki]

Die "abwertende Haltung" habe ich bereits erklärt, EJBs fördern prozedurale Programmierung, nicht Objekt orientierte.
Dazu kommt das Debugging und Fehlersuche zu einer echten Herausforderung damit wird, von der dauer des deployens ganz zu schweigen.

Das es Projekte gibt die Clustering brauchen und daher einen echten Vorteil davon haben EJBs einzusetzen habe ich ja auch nicht bestritten.

Tatsache ist jedoch, dass viel zu oft viel zu schnell zu EJBs gegriffen wird, selbst wenn sie keine echten Vorteile bieten.

Auch ist es Tatsache, das die Opensource Community im Laufe der Zeit alternativen zu EJB geschaffen hat, die für diese Projekte ohne Clustering besser geeignet sind, und sich nun sogar Sun daran Orientiert, siehe zB. die EJB 3 Spek.
Man denke nur an die missgeburten CMP und BMP, 2.x Entity Beans die keine Vererbung unterstützen, etc. pp.

Jedenfalls wenn ich die Wahl zwischen echter OO und EJB habe, brauche ich nicht lange zu Überlegen
Habe aber auch keine Projekte die Clustering brauchen würden.

 

[karatekid]

Debugging und Fehlersuche zu einer echten Herausforderung ? Keine Ahnung worüber du redest. Funktioniert genau so gut. Dauer des Deploys ? Reden wir jetzt über entsprechend große Applikationen wo sich die Dauer das Prozesses kaum noch von den alternativen Technologien unterscheidet ?

Ich kenne beide Seiten und kann nicht feststellen, dass alternative Technologien in der Praxis so viel besser sein sollen. Auch erschließt sich mir nicht, was für ein Problem du mit CMPs hast. Aber evtl. habe ich mich auch die letzten Jahre zu intensiv damit beschäftigt.

Ich will allerdings auch nicht gesagt haben, dass EJBs das Allheilmittel sind.

Aber, du sagst : Tatsache ist jedoch, dass viel zu oft viel zu schnell zu EJBs gegriffen wird,
ich würde es aus meiner Sicht eher so formulieren...
Tatsache ist jedoch, dass EJBs viel zu oft viel zu schnell verteufelt werden weil es ja anders angeblich so einfach geht

Ich glaube irgendwo in der Mitte liegt die Wahrheit

 

[maki]

Auch erschließt sich mir nicht, was für ein Problem du mit CMPs hast. Aber evtl. habe ich mich auch die letzten Jahre zu intensiv damit beschäftigt.

Dann hoffe ich mal das dein Wissen nun nicht ganz nutzlos geworden ist, schliesslich sind sowohl CMP als auch BMP seit EJB 3.0 tot, anscheinend war sogar Sun der Meinung das beide nicht so dolle bzw. "Erhaltenswert" waren...
Zumindest gibt es noch mehr als genug EJB 2.x Projekte die gewartet und erweitert werden müssen.

An ihre Stelle tritt die JPA, und diese ist sehr stark von Hibernate beeinflusst worden

 

[karatekid]

Dann hoffe ich mal das dein Wissen nun nicht ganz nutzlos geworden ist...
Zumindest gibt es noch mehr als genug EJB 2.x Projekte die gewartet und erweitert werden müssen.

Du hast dir deine Frage selbst beantwortet. :wink: Außerdem findet man sich mit diesen Wissen sehr schnell im EJB3 Umfeld zurecht. Und wie bereits erwähnt, ich kenne beide Seiten und habe auch mit Hibernate/Spring gearbeitet.

An ihre Stelle tritt die JPA, und diese ist sehr stark von Hibernate beeinflusst worden

Das habe ich ja auch nicht bestritten. Nur weil sich etwas weiterentwickelt, muss das Alte ja nicht gleich verteufelt werden.

Es ging ja um die angeblichen Probleme mit dem Debugging, der Fehlersuche, dem Deploy, den CMPs usw. Dazu sagst du nichts. Wie gesagt, es war sicher nicht das Allheilmittel für alle Zwecke und mit Sicherheit nicht der Weisheit letzter Schluss.
Aber von den angeblichen Problemen höre ich immer nur von denen die es nicht einsetzten weil es die angeblichen Probleme gibt. :wink:

Aber evtl. hat der Gast doch recht mit seinen Wink auf die Religion... Stichwort "rosarote Brille" Ich schließe mich da nicht aus.

 

[maki]

Nun gut,

wie debugst du deine EJBs?

Wie testest du deine EJBs?

Integrationstest sind unbestrittenerweise aufwändiger zu realisieren als Unittests.
Von der Dauer des Deployens bist du ja direkt abhängig wenn du integrationstests machst, wie oft lässt du denn so deine Tests laufen und wie lange dauert das? Alleine die Zeit die für den Deploy draufgeht um danach die Tests laufen zu lassen ist imho über der Schmerzgrenze.

Mockobjekte? klar machen wir das auch, aber was nutzt das wenn die Tests durchlaufen aber in der EJB dann der identische Code abkackt?

Was ist falsch mit CMP? Soll das ein Witz sein???
Entitäten die andere Entitäten beinhalten sind wohl nicht sehr üblich

Du hast mir immer noch nicht beantwortet, in welchem Punkt ausser dem Clustering EJBs echte Vorteile gegenüber den alternativen bieten?

Rosarote Brillen stehen mir auch sehr gut wie du siehst

 

[karatekid]

wie debugst du deine EJBs?
wie testest du deine EJBs?

remote, funktioniert problemlos

Integrationstest sind unbestrittenerweise aufwändiger zu realisieren als Unittests.

stimmt, hat jetzt aber nix mit dem Thema zu tun.
Wenn du damit allg. Integrationstests im App.Serverumfeld meinst, die sind sowieso aufwändiger als z.B. im Standalone-umfeld.

Von der Dauer des Deployens bist du ja direkt abhängig wenn du integrationstests machst...

...nicht nur beim Integrationstest. Deshalb zerlegt man ja auch große Anwendungen in kleinere Applikationen die dann getrennt deployed, gestartet und gestestet werden können. Mit diesen Mammutapplikationen, aus deren Zeit auch das Argument stammt App.Server seien langsam, so setzt man schon lange keine Projekte mehr um.
Außerdem können die Server "Hotdeploy". Zumindest die Besseren können das. JBoss kann (bzw. konnte, ich kenne die letzten Versionen nicht) das eben genannte alles nicht bzw. nicht korrekt. Da stimmt dann dein Argument mit dem Zeitaufwand. Aber seit dem ich in dem Bereich arbeite, hat keiner der großen Kunden JBoss zu mehr als zum Testen eingesetzt.

Du hast mir immer noch nicht beantwortet, in welchem Punkt ausser dem Clustering EJBs echte Vorteile gegenüber den alternativen bieten?

Gut, da hättest du mich jetzt fast erwischt. Nur habe ich das ja so nicht behauptet. Ich sagte nur, die immer so betonten Nachteile sind nicht wirklich vorhanden bzw. man kann damit leben da auch die Alternativen ihre Grenzen haben. Ich denke da nur an die Tools für Hibernate. Elegant ist was anderes. Was natürlich Murks war und am Anfang der EJB Zeit nervte, waren die nervigen Interfaces. Allerdings hatte man mit denen kaum noch zu tun da diese generiert wurden bzw. von der IDE mitgeflegt wurden. Außerdem ist es ja eh üblich, die DB Schicht zu designen und daraus die Persistenz generieren zu lassen. Das funktioniert übrigens Top/Down und Down/Top bzw. MM. Bis auf Ausnahmen (und Optimierungen) schreibt das heute ja keiner mehr von Hand. IDEs wie z.B. der RAD machen es möglich.
Spätestens wenn du dann in den Bereich der Workflowengines (BEA Liquid, MQ Workflow etc.) kommst, hast du ja eh keine Wahl mehr. Evtl. beim JBoss jBPM.

Also wie gesagt, ich lobe es nicht in den Himmel, ich verteufel es allerdings auch nicht. Richtig angewandt konnte/kann man damit sehr leistungsfähige Applikationen bauen.
z.B. baue ich gerade mit einem Kollegen nebenbei an einer Miniapplikation. Da setzten wir natürlich die Kombination Tomcat/Hibernate ein.

Übrigens, schön das man hier im Forum jemand zum diskutieren findet. Ok, nun mache ich aber erst mal Feierabend.

 

[Ceene]

Oh man da hab ich ja was losgetreten. Wollte doch nur wissen wo es Tutorials gibt :lol:

Habe mich mittlerweile auch mit den EJB3.0 angefreundet und muss sagen das sie einfach zu schreiben gut zu verstehen und auch gut zu testen sind^^

Ich denke es ist geschmackssache was man wie programmiert. Ich werde an den EJB's nicht vorbeikommen da sie in meinem Betrieb benötigt werden.

 

[bronks]

... EJB's ...

Nirgendwo sonst bekommt man automatische Transaktionen und noch dazu verteilte Transaktionen geschenkt.