The EJB Spec requires that every Entity bean also have with it an
EntityKey that is used to look up the bean and compare two
EntityBeans. The
EntityKey is a separate utility class that is developed along with the bean. It generally consists of the key field(s) of the corresponding database row.
EntityKeys are used as a arguments to EJB finder methods and in other places.
KyleBrown
Is there some good argument against using things like java.lang.Integer or java.lang.String as
EntityKey when your keys are only a single field?
AndersBengtsson
Yes, there are some.
One argument for using java.lang.Integer etc is that it saves some coding. (Every line of code is a potential bug!)
One argument for using special key-classes is type-safety. I've been in projects where they used Strings as keys for all entities and passed them around as arguments a lot. There was some spectacular bugs happening when people mixed the different arguments up.
Also, if you have composite keys there really isn't much of a choice.
JonTirsen
As of EJB1.1 it is a custom to use int and String directly without encapsulating them into wrapper classes. You can use Integer and String as
EntityKeys . Or your
EntityKey can be a combination of all the fields (public and persistent) in your
EntityBean. This is very useful if you want have the
EntityBean to represent a table with no primary keys.
-
SeshKumar
EntityKeys are also used to compare two objects. If two
EntityBeans have the same
EntityKey then they are equal. Its different from the reference comparing under corba where we check to see if both objects point to the same chunk of memory in a VM. Fred
-
SeshKumar