Hi,
> 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.
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
relationships should be kept via PK references, and not Handles... Handles
seem more clean, but they are physical-machine specific, i.e. if you migrate
your beans to another server, your serialized Handles are useless.
Hence, you really cannot avoid working with PKs! This is why you should
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".
===========================================================================
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".
