Shiv Kumar wrote:
> Hi
>
> One of the replies said that it would be unmanageable if you have a lot of
> entity beans and a separate PK class is not used. Can you explain me more on
> that?
The two word answer is type safety. For example, given two entities, Contact and
Company, which both have an int primary key, what would prevent using primary key
obtained from a Contact as the primary key in say CompanyHome.findByPrimaryKey?
Nothing. In a simple system with only a few entities, this is unlikely to happen.
But with a complex system with a hundred or more entities and dozens of developers
working on deadline, it will happen and may not be easy to find in testing or code
reviews.
>
>
> Becuse, I dont really see any disadvantage in using java.lang.Integer or other
> wrapper classes for primary key fields. At least now I dont have to write my own
> PK classes (less bugs :-).
You only need to write one class for each data type. Actually you only need to write
one class and then copy if with minor changes for the other data types. You then
subclass these classes for you primary keys. Composite keys will require additional
classes, but it would in with scenario.
<rant>
If java supported parameterized classes, you'd only have to write one primary key
class for simple data types. Get it working once and it works for all. Change it
once for all. Tell me again why java doesn't need parameterized classes?
</rant>
--Victor
===========================================================================
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".
