A Person object can have 0...many Addresses. The addresses are logically a property of the person. Do others normally map this kind of relationship as a standard parent-children (one to many) or as a composite element?

Both mappings imply a different lifecycle, also shared references (a single Address is associated with one/more than one Person) are different. It should be quite straightforward if you know your requirements.

Each address is restricted to the one person, not shared. (Otherwise I'd settle for a straighforward many-to-many mapping). I'm trying to work out what the best policy is before going ahead and coding dozens of classes based on the decision...

I'd probably map the Address as a composite Object. There is a good example of this in Hibernate in Action & it explains why you would choose one over the other quite clearly. It is worth reading the book, it really explains a lot.


HTH
Paul :-)

I will read the book and get the full explanation. What put me off the composite element idea was that it sees you have to specify the properties you are interested in mapping each time. That is, in my Customer mapping, I have a <composite-element> where I specify all the properties of the address and where they are to be mapped. Likewise in Organisation and wherever else. I'd clearly like to be able to do this just once.

Have I misunderstood the way this works?

Yes you would have to map them in each mapping file, but you would still only have one Address class.

If you use one-to-one relationships you would still have to map the relationship in each mapping file. I guess it depends how many classes that have Addresses you have. If you only have a handful of classes it is not that big a deal to map them as composites. It is probably more efficient though to have them as composites. I would really recommend reading the book before making a final decision.


Paul :-)