Hi Thorsten, On Tuesday 09 December 2003 22:01, Thorsten Lamby wrote: > Thanks for your comment, Richard. My main interest of the bean > inheritance was to base dependant objects on an abstract base class (in this > example food based on a animal reference), but > if this is not possible, I have to find some other solutions.
This may be possible, depending on the exact nature of the beans involved :-/
If Animal ist abstract, Food is concrete and the reference is only navigable
from Animal to Food: No problem. AndroMDA will automatically generate
appropriate CMR relations from each concrete animal (Cat, Dog, whatever) to
the corresponding food, and make the getter/setter methods for the relation
available in the Animal entity interface as well.
If the relation is navigable from Food to Animal, things get a bit more
complicated, but it's still possible. What you need to do in this case is:
- set the tagged value "@andromda.ejb.generateCMR" to "false" on the
Animal-Food relation. This tells the EJB cartridge to not generate code (or
rather, XDoclet tags) for a container managed relation, but it will still
generate getter and setter methods on both ends.
- for each concrete animal, model a relation to Food. Set the name of the
relation end on the Food side to the same name as the corresponding end of
the Animal-Food relation ("food" would be appropriate :-). This makes sure
that the abstract getter method in the Animal bean (getFood()) will have an
implementation in each concrete animal. The name of the relation end on the
Animal side, however, must be different from the one used in the generic
relation. A usable pattern is to name it after the concrete type that it
relates to, i.e. getAnimals() for the generic Animal-Food relation, getDogs()
for the Dog-Food relation and so on.
- Implement the generic relation getter/setter (getAnimals()/setAnimals()) by
hand in the FoodBeanImpl. For a *-to-many relation (with Animal at the "many"
ehd), this is quite easy: Simply collect all concrete animals, and return the
combination (this works, because all concrete animals inherit from Animal and
getAnimals() is supposed to return a collection of animals).
From the clients point of view, this relation works exactly as intended. From
the model developers (or deployers, or whoever writes the queries for finder
methods) point of view, however, there is a big difference: For the EJB
container, the "generic" Animal-Food relation does not exist at all. This
means that it cannot be used in a finder query. For example, a query like
"select distinct object(f) from Food f where f.animals.name = 'Boo'" (for
finding the food for all pets named 'Boo') won't work. You'd have to
implement it as "select distinct object(f) from Food f where f.dogs.name =
'Boo' or f.cats.name = 'Boo' or f.fishes.name = 'Boo' ... ".
> So as I understood the EJB concept, the main purpose of the entity beans
> is the object oriented representation of the database tables (and some
> business methods), but the user interface should be build in the session
> beans.
Yes. It's usually a good strategy to treat entity EJBs as dumb (very dumb, in
fact) persistent data containers.
> From my point of view it would make sense that the attributes of
> the entity bean can differ from the one's
> in the attributes of the value object (e.g. to hide some information
> from the user). Can you second that?
Definitely. The attributes will be the same in most cases, but there are quite
a number of cases where you want to hide attributes (mostly technical
artifacts of the persistence layer that should not be seen on the upper
layers, e.g. a type discriminator, if you decide to build the animal type
hierarchy in the value objects, but want to persist all animals in a generic
"Animal" EJB).
> Or should there always be a match for some purpose?
In most cases, there will be a match (the persistence layer models the same
real-life problem as the value objects, after all - no real surprise if they
are similar :-), but there is absolutely no reason that it has to be 1:1
--
Richard Kunze
[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de
pgp00000.pgp
Description: signature
