NHibernate: Pourquoi utiliser <composite-element> sur <one-to-many> pour mapper une collection

Question

Lorsque vous utilisez NHibernate, dans quelles circonstances choisiriez-vous de mapper une collection en utilisant un élément composite pour donner une collection d'objets de valeur, plutôt que de créer une entité à part entière et la cartographie en utilisant un-à-plusieurs?

Vous pourriez avoir une classe de type valeur 'PostalAddress' pour représenter une adresse. Si vous aviez une entité personne et chaque personne pourrait avoir de nombreuses adresses, vous pouvez mapper cette relation comme celui-ci (Option 1):

<bag name="Addresses" table="PersonAddress"> 
    <key column="PersonID"/> 
    <composite-element class="PostalAddress"> 
     <property name="StreetAddress"/> 
     <property name="Town"/> 
     <property name="City"/> 
     <property name="Postcode"/> 
    </composite-element> 
</bag> 

Ou vous pouvez créer une entité « PersonAddress » qui a la propriété de type 'PostalAddress de sur et cartographier les adresses avec un à plusieurs association (option 2):

<bag name="Addresses"> 
    <key column="PersonID"/> 
    <one-to-many class="PersonAddress"/> 
</bag> 

<class name="PersonAddress"> 

    <id name="Id"> 
     <generator class="native"/> 
    </id> 

    <component name="Address" class="PostalAddress"> 
     <property name="StreetAddress"/> 
     <property name="Town"/> 
     <property name="City"/> 
     <property name="Postcode"/> 
    </component> 

</class> 

y a-t-il des raisons de ne pas faire l'option 1? Est-ce que le fait que la table PersonAddress possède une colonne ID suggère qu'elle devrait être une entité elle-même, donc utilisez l'option 2?

Answer 1

< L'élément composite > est pour quand vous avez une collection de valeurs alors que < un-à-plusieurs > est une collection d'entités. La caractéristique déterminante d'une entité est un identifiant unique. Donc, si les articles de votre collection ont un PK, utilisez < un-à-plusieurs >. Sinon, utilisez < élément composite >.

Une autre façon d'y réfléchir est de savoir comment déterminer l'égalité. Est-ce que vous déterminez l'égalité en comparant un ID ou en vérifiant que toutes les propriétés sont identiques? par exemple. Dans votre application, deux objets représentent-ils la même adresse si (address1.Id == address2.Id) ou if (address1.Street == address2.Street & & address1.City == address2.City & & etc.)? Il n'y a pas de bonne réponse universelle car cela dépend du contexte de l'application. Dans de nombreux cas, l'argent est un objet de valeur. Que vous ayez 20 $ ou 20 $, peu importe. Seul le montant est pertinent. Si vous étiez en train de rédiger une demande de suivi pour un atelier de menthe, ils devraient probablement savoir quelle facture de 20 $ vous avez à traiter et vous feriez le suivi du numéro de série sur le billet de 20 $. Dans ce cas, l'argent est une entité. Tout dépend de l'application et du contexte ...