> I have the following design question:
>
> * I have a relational database that has a table called APPLE.
> Each apple has
> a primary key which in my case is an integer.
>
> * I have an entity bean called AppleBean which has a primary key class
> called ApplePK which has an integer (holding my relational
> database integer
> primary key).
>
> * I have a session bean called AppleSupplier which sells apples.
>
> * I have a client (an apple consumer?) that will "BUY" apples from the
> AppleSupplier.
>
> The question is: Should my AppleConsumer know about ApplePK
> and use this to
> buy apples? or should my AppleConsumer use integers (as in
> the database) to
> request apples from the supplier (who will then create
> ApplePKs and deal
> with the apples)?
We have been struggling with a good answer to this question also. On the
face of it, it seems to be a good idea to isolate the client(apple consumer)
from the database schema. Decoupling the schema from the client would
certainly help schema migration that will happen in the future. On the other
hand, primary key classes provide quite a good abstraction for identifying
and distinguishing instances. It seems too fragile to expose primary key
information via a primitive, or set of primitives, to a client. A trade-off
has to be made between flexibility and design transparency.
We have chosen not to expose primary key classes to our clients. Instead,
clients see an opaque method "public Object getID()" on dependent objects
for identifying bean instances. These IDs are in fact entity bean primary
key classes, but the client is not aware of that. The session bean that the
client communicates with has to perform the appropriate mapping between the
opaque id and specific primarykey.
Of course, this opens itself up to an avalanche of ClassCastExceptions if
things get out of sync. To help in this case, we use different dependent
objects for each session bean class. The dependent object is always created
by the same bean that will later do something with the ID via a remote
method. Thus the mapping between the ID and primary key always happens
within one session bean class.
This method isn't perfect, but it allows encapsulation of primary key
information in an object while also permitting a certain degree of
decoupling between the client and database schema.
----
Payam Mirrashidi
[EMAIL PROTECTED]
===========================================================================
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".
