The lifecycle of a pair of Leg depends on the lifecycle of a
Person. Ie. If a Person was deleted from the database, their Legs would be
deleted as well. If you created a Person, their Legs should be created at the
same time. Having 2 EntityBeans, PersonEntity and LegEntity would mean at
least double the number of potential network calls...not a good thing :-)
If you have one PersonEntity then you do not have to worry about deleting the
Leg entities that belong to the deleted PersonEntity. Same for creates.
If an alien came along, the you could model the alien as Alien (plain) with a
Collection of Leg(plain too). When you retrieve the Alien, you get all the
legs in one swoop.
And the much more important point is what if a newer and fancier component
technology came along tomorrow? What are you going do with your EJB references?
As a rule, I find it a terrible idea to mix business/problem/application space
objects with "access" technology such as EJBs. I consider "access
transparency" an important goal in achieving maximum re-use of
business/problem/application logic stuff.
Anh
On Thu, 11 May 2000, Jim Archer wrote:
> --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]
