I have just been thinking about the same thing, and I can think of three
weak arguments in favor of using a pk class.
1) Gives you some room to change the key in that code will be passing
around a FooPK which can be just about anything. This might allow you to
transition from a simple pk to a composite pk with little cost. On the
other hand code which needs to get into the pk will be closely coupled to
it's structure, and IMHO one should use surrogate keys which can just map
onto an Integer or Long.
2) Gives you some type safety in terms of FooPK is clearly different
than BaaPK even though they both might be int's.
3) If you want to use fat keys you'll need a pk class.
An argument against introducing a separate pk class would be to avoid having
an additional class when you don't really need one.
I'd like to hear any good reasons one way or the other as well.
Cheers
-----Original Message-----
From: Tinou Bao
To: [EMAIL PROTECTED]
Sent: 5/22/01 9:04 PM
Subject: non-compound pk
if your primary key is not a compound key but just a simple int or long
is
there any reason to define your own pk class instead of just using the
String class or Long class? does it have anything to do with how well
the
hashcode is distributed?
========================================================================
===
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".
