What about the following:
class One {
long id;
Many[] oneToMany;
}
class Many {
long id;
One one;
}
This seems to work for OODMBS and is also the persistence model chosen
by JavaBlend and Castor for object persistence on top of RDMBS.
In this model One is an entity bean but Many is not a bean by itself,
but accessed through One (since you cannot create/remove a Many without
having a One).
In contrast, if you have a many-many or many-one relationship you get:
class One {
long id;
Many[] manyToMany;
}
class ManyToMany
{
long id;
}
ManyToMany has no association with one, is persisted independently of
one (i.e you can create a new ManyToMany, then create a One that relates
to it). ManyToMany is in itself a bean but there is no reason for One to
access it through the EJB interface (though, it should).
This is also in line with OODMBS, Castor and JavaBlend.
Comments?
arkin
> True, but the shape of your beans are different in each case. eg.
>
> For object databases (as per my understanding of them).
>
> class One {
>
> long id;
> Many[] oneToManyRelationship;
>
> public Many[] getMany() {
> return oneToManyRelationship;
> }
> }
>
> class Many {
>
> long id;
> Many[] manyToOne();
>
> public One getOne() {
> return oneHome.findByMany(this);
> }
>
> }
>
> --or--
>
> For relational databases.
>
> class One {
> long id;
>
> public Many[] getMany() {
> return manyHome.findByOne(this.getPrimaryKey())
> }
> }
>
> class Many {
>
> One manyToOneRelationship;
>
> public One getOne() {
> return manyToOneRelationship.getPrimaryKey();
> }
>
> > The problem here is that whether you use BMP or CMP, Entity beans don't seem to
>give any benefits over simply using Session beans and managing your database mapping
>the normal way for traditional course-grained objects. I want to be proven wrong, but
>I'm still waiting.
>
> That would be my assessment too - if the only thing that Entity beans add is
>persistence, which they don't do particularly well. One other advantage is that they
>can represent a single 'thing' that may take part in transactions, without convoluted
>code in your sessions beans. I have been coding my own non-EJB transactionally-based
>server, and the infrastructure I have built for myself is similar to the (more
>sophisticated) facilities provided by EBJ.
> Hence I have come to appreciate that even though Entity beans don't deliver on
>persistence, there are still a number of good reasons for writing them...the main
>point being that if you don't use them, you will end up writing a whole lot of code
>yourself that is already written for you.
>
> It may be worth looking at the few pre-built Bean packages (eg
>http://www.theorycenter.com/ ) and see how they have chosen to model their beans, and
>consider the design choices that were made.
>
> Good luck,
> David.
>
> --
> David Bullock
> Project Manager - Strategic Applications
> [EMAIL PROTECTED]
>
> "It's no use saying 'We are doing our best.' You
> have got to succeed in doing what's necessary."
> ...Winston Churchill
>
> LISAcorp
> http://www.lisa.com.au/
>
> Adelaide Sydney
> -------------------- ------------------------
> 38 Greenhill Rd Level 3, 228 Pitt Street
> Wayville S.A. 5034 Sydney NSW 2000
>
> PH +61 8 8272 1555 PH +61 2 9283 0877
> FAX +61 8 8271 1199 FAX +61 2 9283 0866
> -------------------- ------------------------
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
