On Thu, 11 May 2000, Thor Heinrichs-Wolpert wrote:
> 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.
I believe we are of the same opinion. Only Person should be modeled as a
PersonEntity (ejb). That is, the PersonEntity bean will contain a
reference to Person (plain java class) which in turn contains references to
his/her Leg(plain java class).
> 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
Well, I don't care whether component != class or not :-) However, I would
never stuff my business level stuff in an EJB (session or entity) directly.
For my appliations, I employ EJB as my personal highway construction crew and
delivery company. Ie, they handle all the infrastructure, packaging, and
delivery stuff, and I handle all the business logic problems.
My applications employ the services of EJB through an abstraction layer - like
shipping containers...stuff clothes, shoes, food, whatever you want in the
containers, and the containers can be shipped wherever by rail, by air, by road,
or by whatever...
EJB today is like a train(?). Tomorrow's EJB may be a spaceship. I would not
want to re-write a single line of my business level code just to use SpaceShip
EJB from WhateverSoft :-). The interface stuff with the SpaceShip EJB would
have to be written, naturally.
Anh
> ----- 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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
