All inline 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 > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of May Charles N > Sent: Wednesday, October 16, 2002 4:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Session Facade's EB placeholders: PKs or Handles? > > > 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. Actually, no, and that is why I pointed to interfaces; you cannot do FECustomerPK customer = new FECustomerPK(); Since FECustomerPK is an interface. Of course, the front-end developer could break this by: A) creating his own class implementing FECustomerPK.(may be even anonymous). It would not be a CustomerPK tough-- you coded that one thus these classes would yield errors if somebody tried to use them. B) Using reflection to obtain info on the fields and modifying them. Both A & B imply a malicious Front End Developer. I'm afraid that EJB cannot help more on the subject without involving the Java 2 security framework(Permissions, etc.) and I'm unsure if this is what you're trying to prevent here. If so, please explain further. If the Front End Developer is considered not to be malicious, then you achieve the desired results by simply not making the actual PK classes available in the classpath. Since all access is achieved thru the interfaces, no creation/tampering could actually take place. Or am I missing something about your particular environment? > > I am interested in the performance gains/losses, though. I > doubt they would be hugely significant, but I'm looking for advice. > I don't think they're significant enough to come into consideration, only type-checking and simplicity came to my mind. I think you'll have to PoC to find out the performance differences for your app server. My 2c, JP =========================================================================== 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".
