The idea is to model your world in a way that is usefull for your purpose.
The person example proposed originally was completely contrived, so its not
really a good one.
Lets say we have a machine. If the machine is a small portion of our
overall system which provides services to us, we can make it its own little
object with a public inteface thats usefull to us. However, if we are
modeling the machine itself, then there are probably many classes (types)
that comprise the machine.
EJB should allow us to model our world in a usefull way without having to
worry about the underlieing persistance layer. We should (and usually can,
but not always) be able to construct a nice OO model. Key to this is
allowing entities to compose and aggregate other entities. If an EJB server
fails to support this, then the developers are forced to do a lot of work
to support relationships between entities and this work really has little
to do with their model and a lot to do with implementation.
As for a UI example, usually a class is designed to represent the smallest
unit that is independantly usefull, for code reuse purposes.
--On Thursday, May 11, 2000 11:02 PM -0700 Thor Heinrichs-Wolpert
<[EMAIL PROTECTED]> 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. 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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
