>> Hopefully relational storage will become extinct, but I'm not holding my
breath.
Good, because you'd die. And I don't want you to because your posts are a
good read.
One of the useful things that O/R mapping tools provide is the ability to
map multiple overlapping objects onto a single physical store. The EJB
model is designed for the solution builder to collect and integrate
business objects from domain providers which are separate entities, and you
don't have or want their source code. When there's more than one domain
involved in the solution, there's always attribute overlap (every domain
has their own "User" object, and half of the domains have a "Customer"
object).
The object persistence mechanisms don't go there, which functionally makes
it a hole. I can't use an object container and get "com.acme.Person" to
project onto my existing "com.widgets-inc.Person", with all the rich O/R
mapping techniques like expressions and function conversions to do the
projection/mapping (e.g. com.acme.Person.isMale() is a boolean attribute,
but com.widgets-inc.Person.getGender() returns int (Person.MALE=0,
Person.FEMALE=1)).
Nature abhors a vacuum, and so does my architecture diagram. That leaves
O/R mappers filling a role that is not otherwise addressed in the object
containers I've seen. And I don't know if I ever will see things like a
TOPLink container for GemStone/J (for example...), because I know that's
not where those vendor's heads are at. What would you call such a product
anyway? A "non-relational object/relational mapper"? That'd be fun to try
and market (not).
David
Chip Wilson <[EMAIL PROTECTED]> on 05/05/99 11:28:35 AM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: David Rauschenbach/ZLAND)
Subject Re: Granularity of EJBObjects
:
> -----Original Message-----
> From: Brian N. Miller [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 05, 1999 9:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Granularity of EJBObjects
>
> Someone wrote:
> >
> >I have found that it is best for entity beans to be large/coarse
> >grained components which represent a graph of domain instances. Each
> entity
> >bean has a single root domain object, and the entity represents all
> domain
> >objects referenced from this root.
>
> That would work just fine with Java's default
> serialization-by-reachability,
> but would be painful to map to relational. Hopefully relational storage
> will
> become extinct, but I'm not holding my breath.
>
[Chip Wilson]
Mapping a domain object model to a relational database is always
painful, assuming that the domain model is of high quality. This doesn't
change if entity beans are fine-grained domain objects. The only way to
simplify is to sacrifice your domain and map entity beans to tables, or
sacrifice your relational model and go object dB. I concur with your
assessment of the likelihood of the latter.
>
==========================================================================
> =
> 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".
===========================================================================
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".
