>
> > I always use
> > public void processTransaction(Customer c, Itinerary i, etc.)
> >so as to hide the PKs from the client.
>
> Of course, when you say "client" you mean client of session
> beans, and yes,
> from that perspective the client should only manipulate a
> single session
> bean home, a single session bean instance, and pass in only business
> objects.
Actually, I hide the PKs both from non-EJB clients and from EJB clients.
>
> However, when you are writing a Session Bean (client of the
> entity bean),
> you WANT to work directly with PKs! Most server vendors
> (e.g. Weblogic)
> optimize caching of PKs. Hence you will want to do searchs
> on PK rather
> than another attribute, via findByPrimaryKey(). Also, bean-to-bean
I believe using the remote reference should be as efficient, if not more, as
using the primary key and findByPrimaryKey. At the very least I avoid
another remote call.
> relationships should be kept via PK references, and not
> Handles... Handles
I do keep the relationships by PKs. I just don't expose them.
The PK is just a getPrimaryKey() call away.
Instead of passing in the PKs and invoking findByPrimaryKey() when
necessary, I pass in the remote reference and invoke getPrimaryKey() when
necessary. Otherwise the approaches are equivalent.
> seem more clean, but they are physical-machine specific, i.e.
> if you migrate
The code is portable, and as I don't store remote references or handles in
the database, so is the data.
> your beans to another server, your serialized Handles are useless.
>
> Hence, you really cannot avoid working with PKs! This is why
> you should
I work with PKs, but only at the lowest possible level (i.e. the entity
implementations)
> typesafe your PKs.
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Avi Kivity
> Sent: Wednesday, August 02, 2000 11:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: int as Primary Key
>
>
> > Hi,
> >
> > No problem. What I originally said was if you have many
> > different types of
> > entity beans, and use session beans that work on them (common
> > model-controller pattern), your session bean functions will
> > look something
> > like this:
> >
> > public class TravelAgentBean
> > extends SessionBean
> > {
> > //this is what a function looks like if you use
> > generic wrapper PKs
> > public void processTransaction(Integer aCustomerPK, Integer
> > aItineraryPK, Integer aCreditCardPK, Integer aAddressPK...);
> >
> > //this is what a function looks like if you use
> > custom class PKs
> > public void processTransaction(CustomerPK
> > aCustomerPK, ItineraryPK
> > aItineraryPK, CreditCardPK aCreditCardPK, AddressPK aAddressPK...);
> > }
>
> I always use
>
> public void processTransaction(Customer c, Itinerary i, etc.)
>
> so as to hide the PKs from the client. Likewise, I hide all
> EJBHome calls in
> the bean implementation, so that clients only have to pick up
> a single home
> and can traverse the persistent object graph using only the remote
> interfaces.
>
> >
> > Now do you see the problem? The first function is not
> > typesafe at all!
> > Sure, the arg names clearly label what the user should pass in, but
> > developer of this bean is basically counting on the
> > competency of the user
> > to pass in the correct corresponding PK values without any
> > compile-time
> > checks! Should a user make a mistake and swap two arguments,
> > where will
> > this be caught? Chances are, it probably won't, and someone
> > else will be
> > footing the bill for another's free vacation! Debugging can
> > be a nightmare!
> >
> > The moral of this is: sure, custom PKs require a little more
> > effort (not
> > really much more... just have a custom classes that wrap
> Integers or
> > Longs!), but you will appretiate your efforts in the long run!
> >
> > Gene
>
>
- Avi
--
s/\be(\w+)/e-\1/g;
===========================================================================
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".
