Well, unless you are selling prosethetics or high-end sports equipment,
you'd have a tough time convincing me that a persons leg is a separate
entity and not a dependent object. Again I think it comes back to the point
of where do you draw a line about a component? Component heritage, as far
as I can see, is more from UI development, and we are now trying to move
that success to business things. In the case of a UI component, would you
make every piece of a slider a component, or every piece of a button? There
can always be arguments to make them into a collection of components, but
usually they are a single component. Should a business object be a complex
component, or a simple normalized piece that has limited function? In the
case of your "person" example (being that component != class) would you want
to assemble all the little components that could be broken down and make up
a person, or do you want to plunk down a networked transactional business
component that represents a person and work with that?
If I'm just wrapping each object into an EJB, then it's not really a
compnent??
Thor HW
----- Original Message -----
From: "Jim Archer" <[EMAIL PROTECTED]>
To: "EJBoss" <[EMAIL PROTECTED]>
Sent: Thursday, May 11, 2000 10:01 PM
Subject: Re: O->R Stuff Re: Seems like a big POS
>
>
> --On Thursday, May 11, 2000 6:34 PM -0700 Phan Anh Tran <[EMAIL PROTECTED]>
> wrote:
>
>
> > As you can see, it would be highly inappropriate to implement a
> > PersonEntity and a LegEntity to wrap Person and Leg respectively. It
> > makes more sense to have one PersonEntity bean with a reference to
Person
> > which in turn has a reference to Leg.
>
> I don't see this...
>
> In ths case, it would be very reasonable to have a person entity that had
> two references, one to a left leg entity and another to a right leg
entity.
> If we had some kind of alian that had an unknown number of legs, it would
> be reasonable for a person entity to have a Collection of leg entities. I
> don't see why a PersonEntity should have a Person that in turn has a
> reference to a leg.
>
> If you need to find all the people with legs of a particular length, then
> give each LegEntity a reference to their corresponding PersonEntity. Put a
> finder method in the leg that returns a person entity.
>
> Jim
>
>
>
> >> Workaround:
> >> use EntityBeans for everything. Then they will be searchable. Perhaps
> >> not the most "clean" or "OO", but works.
> >>
> >> Once EJB 2.0 defines how to do this, we will implement this.
> >>
> >> /Rickard
> >
> > Is EJB 2.0 going to define how to map a certain class or how to specify
> > custom finder methods or both? I am not at all familiar with what is
> > going to be in EJB2.0. However, consider this:
> >
> > public class Person
> > {
> > private Leg leftLeg;
> > private Leg rightLeg;
> > }
> >
> > public class Leg
> > {
> > private byte length;
> > }
> >
> > [Person]<>----(2)->[Leg]
> >
> > As you can see, it would be highly inappropriate to implement a
> > PersonEntity and a LegEntity to wrap Person and Leg respectively. It
> > makes more sense to have one PersonEntity bean with a reference to
Person
> > which in turn has a reference to Leg.
> >
> > However, the business logic may require the need to find all people with
> > legs of a certain length. In order to support the described query
> > efficiently, one would need to map Person to a Table Person and
> > rightLeg/leftLeg to a Table Leg.
> >
> > If one did not map rightLeg and leftLeg to a separate table, one would
be
> > forced to load all PersonEntity bean one at a time and check their
legs -
> > a much more inefficient approach than a straight database level sql
join.
> >
> > On the other hand, if there never is a nee to find all people with legs
of
> > certain length, the bean deployer could choose to stuff the
> > rightLeg/leftLeg stuff in one column in the Table Person.
> >
> > I just want to make sure that EJB2.0 is going to deal with the above
O->R
> > mapping issues.
> >
> > Anh
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
>
>
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
