Unfortunately, this approach to composite identifiers means that a persistent object is its own identifier. There is no convenient "handle" other than the object itself. You must instantiate an instance of the persistent class itself and populate its identifier properties before you can load() the persistent state associated with a composite key.

We will describe a much more convenient approach where the composite identifier is implemented as a seperate class in Section 7.4, “Components as composite identifiers”. The attributes described below apply only to this alternative approach:

*

name (optional, required for this approach): A property of component type that holds the composite identifier (see next section).
*

access (optional - defaults to property): The strategy NHibernate should use for accessing the property value.
*

class (optional - defaults to the property type determined by reflection): The component class used as a composite identifier (see next section).