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".

Reply via email to