You drive a reasonable argument to use primary keys instead of Handles. As I
mentioned, our Primary Keys are already type-safe which is consistent with what you
suggest. What I'm concerned about is the object-purist notion that the front end
should never be able to play directly with the values of the primary keys themselves.
Using Handles seems more object-oriented in that the values of the primary keys are a
black box to front-end developers. It's more like Java references: the binary value of
an Object reference is irrelevant to the user and should not be changeable -- it's
what the reference points to that is important.
Bear with me for a simple analogy. As I'm sure you know, unlike C, Java disallows the
programmer from making an object reference point to something other than a real Object
(or null). Passing and manipulating primary keys is much more C-like in that the
values of the primary keys can be manipulated (ahem, screwed up to point to garbage)
by a front-end developer, whereas if handles get passed then the values which
represent EJBs would always represent either a genuine entity instance or null.
I am interested in the performance gains/losses, though. I doubt they would be hugely
significant, but I'm looking for advice.
-Charles May
On Wed, 16 Oct 2002 15:56:29 +0100, Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote:
>Handles usually persist the PK and the EJBHome JNDI binding and make the
>proper lookups(lookup home, then lookup bean using the PK). There is no
>evident gain of using handles, and many will also point to the original
>server instance(it really depends on the implementation of the server,
>but this is the most common case). Perhaps you could test you particular
>app server, but I doubt that
>
>Regarding the possible manipulation of PKs, simply encapsulate them:
>
>public interface FrontEndPK extends java.io.Serializable {
>}
>
>public interface FECustomerPK extends FrontEndPK {
> public String getFullName(); // maybe allow some access to some
>properties???
>}
>
>Making your PKs implement FrontEndPK instead of Serializable. Inmediate
>downside is that you would have to implement a PK class even for PKs
>that map to existing classes (like String or Long). Or just use
>Serializable as the return format for PKs. Either way, your Outer Facade
>would look like this:
>
>public FrontEndPK findCustomer(String param);
>public java.io.Serializable findCustomer(String param);
>public void deposit(FrontEndPK customer, double amount);
>public void deposit(FECustomerPK customer, double amount); // leverages
>strong type checking
>
>Since from what you tell no interaction with PKs is needed, just the
>ability of the FrontEnd to obtain PKs from the Outer Facade and be able
>to store them, then this should be enough(in reality it might be
>different, if so, please explain further).
>
>My 2c,
>
>Juan Pablo Lorandi
>Chief Software Architect
>Code Foundry Ltd.
>[EMAIL PROTECTED]
>
>Barberstown, Straffan, Co. Kildare, Ireland.
>Tel: +353-1-6012050 Fax: +353-1-6012051
>Mobile: +353-86-2157900
>www.codefoundry.com <http://www.codefoundry.com/>
>
>Disclaimer:
>
>Opinions expressed are entirely personal and bear no relevance to
>opinions held by my employer.
>Code Foundry Ltd.'s opinion is that I should get back to work.
>
===========================================================================
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".
