Russell Gold wrote:
> It is a novella, republished in "Inconstant Star" by Anderson. ISBN 0-671-72031-7.
Thanks.
> But this seems to defeat the whole point of having entity beans. Why not just have
>the session beans call the stuff which does the SQL? The promise of Entity beans was
>that you could use container-managed persistence and not have to write SQL, or that
>any SQL you did write was only needed in the persistence methods, not the business
>methods.
I don't think CMP delivers on the promise of persistence - at least not in a way that
is congruent to domain-object modelling. Entity beans and a persistent object model
are not the same thing. If you like, you could look at object-relational tools
instead. Depending on the nature of your application, it might be an appropriate
technology to use. A good reference for looking up O-R products is:
http://www.ambysoft.com/persistenceLayer.html
> >In particular, the 'Pass by Value' paper by Richard Monson-Haefel is quite relevant
>to what I discuss here.
>
> I'm afraid I don't see the connection. I do agree that using pass-by-value over
>networks is the way to go, but it does not address the persistence issue at all.
True, the paper deals with a motivation for coarseness, not with persistence issues
per-se.
> >That's about it. This might be bad news concerning CMP, but Container managed
>persistence is a white elephant anyway - it is not portable between an Object
>Database and a Relational Database, because in ODBMS relationships, the ONE contains
>references to the MANY, while in an RDBMS relationships, each MANY holds a reference
>to the ONE. This obviously affects how you model your EJB's!
>
> I don't agree. You can model a one-to-many or a many-to-one relationship in either
>kind of database.
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".
