EJB Entities aren't fully OO, because they must support most persistance
managers (and most are RDBMS)
Polymophism isn't supported by java by multiple inheritance but by multiple
interfaces;
not an object oriented approach, but a component oriented approach.
Object Aggregations, and n..n relathionships DO map seamlessly to a
relational data model; the problem
usually shows up whenever you're trying to optimize finders that should work
across entities (involve more than one entity type) when using CMP.
Basically, the most noticeable problem in EJB 1.1 is (altough there are
workarounds that don't conform to the spec):
EJB is basically spinning around a component oriented concept of code reuse
strongly based on encapsulation(in contrast to inheritance) that enables
some sort of transparent indirection, that is
I DON'T know or have to know:
how the server handles Tx's
how entities are persisted/unpersisted
how finders map to a RDBMS
etc.
But, on the other hand, the spec has a lot of room to mature on(as proved by
the large differences between 1.1 and 2.0pfd) and some issues that the spec
must define are undefined.
Improvements are (hopefully) on the way... or we'll all be forced to switch
to .Net (ROTFL)
My 2c,
JP
> -----Original Message-----
> From: Edward Yeboah [mailto:[EMAIL PROTECTED]]
> Sent: Martes, 20 de Febrero de 2001 10:41
> To: [EMAIL PROTECTED]
> Subject: Re: Applicability of EJB - just a thought
>
>
> If your model cannot accomodate pre-built components
> and tries to model everything down to the last detail,
> you are in trouble for a start.
>
> Maybe you should rethink your approach here. OO design
> anticipates use of components.
>
> Anyhow, your design should not have anything directly
> to do with EJB. EJB is an implementation issue.
> What if tomorrow, EJB becomes (God forbid EJBDCOM) then
> what do you do. Redesign?
>
> Edward
>
> > Hi,
> >
> > I think the applicability of EJB is limited when it comes
> to modeling
> > complex
> > OO scenarios, for two main reasons:
> >
> > a) EJB does not support inheritance (at least EJB 1.1 does
> not), so you
> > have
> > to come up with ugly workarounds if you want to use
> polymorphism, for
> > example
> >
> > b) Object aggregations don't map very well to the
> relational data model.
> > The
> > main reason is that in OO, you usually have a reference
> from the parent to
> > the child objects, like in a Vector or an array. In the
> relational model,
> > you
> > always have children reference the parent (exactly the
> other way round).
> >
> > These problems are very moderate when modeling such
> scenarios as the usual
> > online shops, which have rather low structural complexity.
> However, if the
> > model gets more complex and you need to make heavy use of
> > inheritance/aggregations, you run into trouble
> >
> > Any comments?
> >
> > cu
> > Heiko
> >
> >
> ==============================================================
> =============
> > 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".
> >
>
> --
> Sent through GMX FreeMail - http://www.gmx.net
>
> ==============================================================
> =============
> 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".
