Hibernate supporte les trois stratégies d'héritage de base : une table par hiérarchie de classe (table per class hierarchy) une table par classe fille (table per subclass) une table par classe concrète (table per concrete class) Hibernate supporte en plus une quatrièmestratégie, légèrement différente, qui supporte le polymorphisme : le polymorphisme implicite Il est possible d'utiliser différentes stratégies de mapping pour différentes branches d'une même hiérarchie d'héritage, et alors d'employer le polymorphisme implicite pour réaliser le polymorphisme à travers toute la hiérarchie. Pourtant, Hibernate ne supporte pas de mélanger des mappings <subclass> et <joined-subclass> et <union-subclass> pour le même élément <class> racine. Il est possible de mélanger ensemble les stratégies d'une table par hiérarchie et d'une table par sous-classe, pour le même élément <class>, en combinant les éléments <subclass> et <join> (voir dessous). Il est possible de définir des mappings de subclass, union-subclass, et joined-subclass dans des documents de mapping séparés, directement sous hibernate-mapping. Ceci vous permet d'étendre une hiérarchie de classe juste en ajoutant un nouveau fichier de mapping. Vous devez spécifier un attribut extends dans le mapping de la sous-classe, en nommant une super-classe précédemment mappée. Note : précédemment cette foncionnalité rendait l'ordre des documents de mapping important. Depuis Hibernate3, l'ordre des fichier de mapping n'importe plus lors de l'utilisation du mot-clef "extends". L'ordre à l'intérieur d'un simple fichier de mapping impose encore de définir les classes mères avant les classes filles. ]]> Supposons que nous ayons une interface Payment, implémentée par CreditCardPayment, CashPayment, ChequePayment. La stratégie une table par hiérarchie serait : ... ... ... ... ]]> Une seule table est requise. Une grande limitation de cette stratégie est que les colonnes déclarées par les classes filles, telles que CCTYPE, ne peuvent avoir de contrainte NOT NULL. La stratégie une table par classe fille serait : ... ... ... ... ]]> Quatre tables sont requises. Les trois tables des classes filles ont une clé primaire associée à la table classe mère (le modèle relationnel est une association un-vers-un). Notez que l'implémentation Hibernate de la stratégie un table par classe fille ne nécessite pas de colonne discriminante dans la table classe mère. D'autres implémentations de mappers Objet/Relationnel utilisent une autre implémentation de la stratégie une table par classe fille qui nécessite une colonne de type discriminant dans la table de la classe mère. L'approche prise par Hibernate est plus difficile à implémenter mais plus correcte d'une point de vue relationnel. Si vous aimeriez utiliser une colonne discriminante avec la stratégie d'une table par classe fille, vous pourriez combiner l'utilisation de <subclass> et <join>, comme suit : ... ... ... ... ]]> La déclaration optionnelle fetch="select" indique à Hibernate de ne pas récupérer les données de la classe fille ChequePayment par une jointure externe lors des requêtes sur la classe mère. Vous pouvez même mélanger les stratégies d'une table par hiérarchie de classe et d'une table par classe fille en utilisant cette approche : ... ... ... ... ]]> Pour importe laquelle de ces stratégies, une association polymorphique vers la classe racine Payment est mappée en utilisant <many-to-one>. ]]> Il y a deux manières d'utiliser la stratégie d'une table par classe concrète. La première est d'employer <union-subclass>. ... ... ... ... ]]> Trois tables sont nécessaires pour les classes filles. Chaque table définit des colonnes pour toutes les propriétés de la classe, incluant les propriétés héritéés. La limitation de cette approche est que si une propriété est mappée sur la classe mère, le nom de la colonne doit être le même pour toutes les classes filles. (Nous pourrions être plus souple dans une future version d'Hibernate). La stratégie du générateur d'identifiant n'est pas permise dans l'héritage de classes filles par union, en effet la valeur (NdT : seed) de la clef primaire doit être partagée par toutes les classes filles "union" d'une hiérarchie. Si votre classe mère est abstraite, mappez la avec abstract="true". Bien sûr, si elle n'est pas abstraite, une table supplémentaire (par défaut, PAYMENT dans l'exemple ci-dessus) est requise pour contenir des instances de la classe mère. Une approche alternative est l'emploi du polymorphisme implicite : ... ... ... ]]> Notez que nulle part nous ne mentionnons l'interface Payment explicitement. Notez aussi que des propriétés de Payment sont mappées dans chaque classe fille. Si vous voulez éviter des duplications, considérez l'utilisation des entités XML (cf. [ <!ENTITY allproperties SYSTEM "allproperties.xml"> ] dans la déclaration du DOCTYPE et &allproperties; dans le mapping). L'inconvénient de cette approche est qu'Hibernate ne génère pas d'UNIONs SQL lors de l'exécution des requêtes polymorphiques. Pour cette stratégie de mapping, une association polymorphique pour Payment est habituellement mappée en utilisant <any>. ]]> Il y a une chose supplémentaire à noter à propos de ce mapping. Puisque les classes filles sont chacune mappées avec leur propre élément <class> (et puisque Payment est juste une interface), chaque classe fille pourrait facilement faire partie d'une autre hiérarchie d'héritage ! (Et vous pouvez encore faire des requêtes polymorphiques pour l'interface Payment). ... ... ... ... ]]> Encore une fois, nous ne mentionnons pas explicitement Payment. Si nous exécutons une requête sur l'interface Payment - par exemple, from Payment - Hibernate retournera automatiquement les instances de CreditCardPayment (et ses classes filles puisqu'elles implémentent aussi Payment), CashPayment et ChequePayment mais pas les instances de NonelectronicTransaction. Il y a certaines limitations à l'approche du "polymorphisme implicite" pour la stratégie de mapping d'une table par classe concrète. Il y a plutôt moins de limitations restrictives aux mappings <union-subclass>. La table suivante montre les limitations des mappings d'une table par classe concrète, et du polymorphisme implicite, dans Hibernate. Stratégie d'héritage many-to-one polymorphique one-to-one polymorphique one-to-many polymorphique many-to-many polymorphique load()/get() polymorphique Requêtes polymorphiques Jointures polymorphiques Récupération par jointure externe une table par hiérarchie de classe <many-to-one> <one-to-one> <one-to-many> <many-to-many> s.get(Payment.class, id) from Payment p from Order o join o.payment p supportée une table par classe fille <many-to-one> <one-to-one> <one-to-many> <many-to-many> s.get(Payment.class, id) from Payment p from Order o join o.payment p supportée une table par classe concrète (union-subclass) <many-to-one> <one-to-one> <one-to-many> (pour inverse="true" seulement) <many-to-many> s.get(Payment.class, id) from Payment p from Order o join o.payment p supportée une table par classe concrète (polymorphisme implicite) <any> non supporté non supporté <many-to-any> s.createCriteria(Payment.class).add( Restrictions.idEq(id) ).uniqueResult() from Payment p non supportées non supportée