Ensure a one to one (distinct) relation when using one to many (subclassed) - nhibernate

Question

My scenario is that I have a User class, and that class has to be extended with related data, but without being subclassed.
For example the user might have lots of different profile data: AddressProfileData, FavoritesProfileData, etc etc.
I have decided to go with an abstract class and many implementations, kind of like in this post: inheritance mapping
However, I can't find a way to ensure (using nhibernate and not programmatically) that each item, for example AddressProfileData occurs only once per user.
Is this possible? If not, is there another solution for this problem which is more proper? I feel that sharing a common abstract class is building my app around NHibernate, and not the other way round.

Answer 1

AddressProfileData and FavoritesProfileData are likely to share almost nothing common, except for the fact that they both are extra information you attach to a User, so I don't think it makes sense to make them part of some inheritance hierarchy. Instead, I would go with something like this:
public class User
{
// ... other properties ...
public virtual AddressProfileData Address { get; set; }
public virtual FavoritesProfileData Favorites { get; set; }
}
public class AddressProfileData
{
// ... other properties ...
public virtual User User { get; set; }
}
<class name="User">
<!-- ... other properties ... -->
<one-to-one name="Address" property-ref="User" />
<one-to-one name="Favorites" property-ref="User" />
</class>
<class name="AddressProfileData">
<!-- ... other properties ... -->
<many-to-one name="User" column="User_id" unique="true" not-null="true" />
</class>
create table AddressProfileData (
/* ... other columns ... */
User_id int not null,
unique (User_id),
foreign key (User_id) references User (Id)
);
I'm sure you can imagine what FavoritesProfileData looks like.
With this setup, you ensure that each type of profile data only occurs once per user, and you also don't wind up in a weird place where you have to test which type of ProfileData you're dealing with before you can do anything with it. You always know exactly what kind of profile data you're touching.