[J2EE] Inheritance en EJB

[Casteloni]

Voor mijn stage ben ik bezig met een project dat ontwikkeld wordt in Java op het J2EE platform. Ik ben nu bezig met een klassendiagram / TO en loop nu tegen een design-issue aan.

Er is een (web)applicatie waar verschillende soorten klanten op kunnen inloggen. Er zijn 3 soorten klanten : Directe, Indirecte en Contactpersonen. In UML heb ik het zo gemodelleerd:



De 3 verschillende klanten erven de gezamenlijke eigenschappen van de Base-class. Als een klant nu inlogt d.m.v zijn gebruikersnaam en wachtwoord wordt er via de KlantEJB gekeken of deze bestaat.

Het probleem is nu dat ik niet alleen de algemene klant gegevens wil hebben, maar ook de specifieke.

De oplossing die ik zelf bedacht heb, is om een extra attribuut aan de Base-class toe te voegen: klant_type, en dan vervolgens met een if / switch statement een ejbSelect-query uit te voeren die dan een IndirectKlant object returned.

Ik zie hier wel een aantal nadelen:

• De code is minder schaalbaar, voor elke klanttype moet er nieuwe switch/if komen.
• Wat zou er gebeuren als ik van het IndirecteKlantEJB de voornaam opvraag? ( dit ga ik morgen proberen )

Nu is dit nog een vrij kleinschalige applicatie. Hoe zou je dit in een grote J2EE-applicatie oplossen? Is er misschien een betere oplossing die de applicatie en schaalbaar houd en niet te ingewikkeld is?

Op ONJava.com staat nog een leuk artikel over Inheritance in J2EE

[Alarmnummer]

Waarom wil je werken met EJB?? Er zijn tegenwoordig veel lichtere J2EE oplossingen waarbij je volledige vrijheid hebt. Check bv het Spring framework, hibernate, picocontainer. Je hebt dan volledige bewegingsvrijheid.

EJB in zijn huidige vorm is passee. In EJB 3.0 gaan ze ook toe naar een veel lichtere vorm. Dus.. vraag je heel goed af waarom je in godsnaam met EJB zou willen werken.

[Robtimus]

Met getClass() werken helpt niet?
Simpele check:

Java:

if (klant.getClass() == ContactPersoon.class)
{
    // code
}

instanceof kan ook als subclasses ook toegestaan zijn.

[Casteloni]

Interessant opmerking, ik was tot nu wel tevreden over de EJB's. Heb je misschien nog een artikel die dit ondersteunt?

De reden waarom ik EJB's gebruik is omdat dit al een lange tijd van de te voren is vastgesteld, staat ook in mijn stage-opdracht enzovoorts. Het project is ondertussen in een zodanig ver gevorderd stadium dat het heel veel tijd gaat kosten om over te stappen naar een ander framework.

Gelukkig heb ik wel een oplossing die dan misschien niet heel erg mooi en schaalbaar is. In het kader van mijn stageopdracht moet ik op het einde natuurlijk ook iets over J2ee vertellen, als het nou echt blijkt dat dit eigenlijk niet een goed framework is om mee te ontwikkelen dan is dat een mooi moment om dat te vertellen.

Mocht iemand nog een mooie oplossing hebben dan hoor ik het graag!

edit: Dan zou een selecQuery op KlantEJB een DirecteKlant moeten returnen, maar het lijkt me sterk dat het zo werkt.

[ Voor 8% gewijzigd door Casteloni op 18-11-2004 20:58 . Reden: reactie op IceManX ]

[Alarmnummer]

Better faster lighter Java
(Komt mijn signature ook vandaan)

Expert One-on-One J2EE Development without EJB

Artikel op the serverside

[PhoneTech]

VampireSlayer schreef op donderdag 18 november 2004 @ 20:52:
Interessant opmerking, ik was tot nu wel tevreden over de EJB's. Heb je misschien nog een artikel die dit ondersteunt?

De reden waarom ik EJB's gebruik is omdat dit al een lange tijd van de te voren is vastgesteld, staat ook in mijn stage-opdracht enzovoorts. Het project is ondertussen in een zodanig ver gevorderd stadium dat het heel veel tijd gaat kosten om over te stappen naar een ander framework.

Gelukkig heb ik wel een oplossing die dan misschien niet heel erg mooi en schaalbaar is. In het kader van mijn stageopdracht moet ik op het einde natuurlijk ook iets over J2ee vertellen, als het nou echt blijkt dat dit eigenlijk niet een goed framework is om mee te ontwikkelen dan is dat een mooi moment om dat te vertellen.

Mocht iemand nog een mooie oplossing hebben dan hoor ik het graag!

edit: Dan zou een selecQuery op KlantEJB een DirecteKlant moeten returnen, maar het lijkt me sterk dat het zo werkt.

In mijn afstudeer project moet ik ook gebruik maken van EJB's.

EJB is bloat. veel bloat. overhead is groot, en het is allemaal behoorlijk log. Maar xDoclet maakt het een stuk makkelijker voor je.

Wij hebben hier een ejb model met ongeveer 45 CMP beans. Het wordt sterk afgeraden om inheretance te gebruiken als je veel data hebt. Dus we hebben het EJB model gebouwd op performance, en via assamblers naar een stuk of 20 dto's gemapped die weer makkelijk aan de client te gebruiken zijn.

En als je met xDoclet werkt, laat xDoclet niet de DTO's (VO's) genereren. Uiteindelijk wil je het toch in je eigen custom dto's gebruiken.

[Casteloni]

Gelukkig is de applicatie waar ik aan werk niet zo heel erg groot. Een stuk of 20 Entity Beans en een aantal session beans.

Ik heb ook geprobeerd met xDoclet te werken maar vond het niet echt handig. Ik vind dat je dan minder controle over je code en deployment descriptors hebt. Daar ben ik inmiddels vanaf gestapt.

DataTransferObjects gebruik ik (nog) niet. Als ik het goed begrepen heb zijn dat alleen klassen met getters / setters? De entitybean heeft naast deze getters/setters ook nog de business methods. Zie ik dat zo goed?

Mijn entitybeans bevatten niet zo heel erg veel business-methods (sommige zelfs geen), dus daar zou ik dan geen DTO's voor moeten gebruiken? Ik denk dat dit project een belangrijke stap is op het hele leertraject en dat er nog veel dingen aan mijn ontwerp verbeterd kunnen worden.

Verder ben ik nu dus bezig om die ejb's te laten erven van een base-class. Het is me inmiddels gelukt om ze te deployen

[Alarmnummer]

VampireSlayer schreef op vrijdag 19 november 2004 @ 10:51:
DataTransferObjects gebruik ik (nog) niet. Als ik het goed begrepen heb zijn dat alleen klassen met getters / setters? De entitybean heeft naast deze getters/setters ook nog de business methods. Zie ik dat zo goed?

Het doel achter een DTO is dat je van een finegrained interface gaat naar een course grained interface (in het nederlands: ipv een hele zooi set/get calls pomp je een 'dummy' object het netwerk over waarin alle informatie staat). In beide gevallen wordt dezelfde data overgezonden, maar de overhead (qua netwerk communicatie) bij de laatste is een orde van grote kleiner.

[ Voor 39% gewijzigd door Alarmnummer op 19-11-2004 11:07 ]