Cette fois, parlons de la conception hiérarchique de Hibernate, qui est la conception de la relation successive entre les entités.
Peut-être que c'est plus abstrait, regardons directement les exemples.
1) Regardons d'abord la pratique commune et entrons directement le code: les trois classes réelles sont les suivantes:
classe publique TitEm implémente Serializable {// omettre get / set Method private int id; Fabrication de cordes privée; nom de chaîne privé; } classe publique TBOOK étend Titem {// Omit Get / Set Method private int pageCount; } classe publique TDVD étend TitEm {// Omit Get / Set Method private String RegionCode; }
Ici, nous avons besoin de trois fichiers de mappage, le contenu est le suivant:
<class name = "titem" table = "item"> <id name = "id" colonnen = "id" type = "java.lang.integer"> <générateur /> </ id> <propriété name = "name" colonnel = "name" type = "java.lang.string" /> <propriété name = "manufacture" colonnes = "manufacture" type = "java.lang.string" /> </ class> <class " name = "tBook" table = "book"> <id name = "id" colonnen = "id" type = "java.lang.integer"> <générateur /> </ id> <propriété name = "name" colonnel = "name" type = "java.lang.string" /> <propriété name = "manufacture" colonnes = "manufactun" type = "java.lang.string" Column = "PageCount" type = "java.lang.integer" /> </ class> <class name = "tdvd" table = "dvd"> <id name = "id" column = "id" type = "java.lang.integer"> <générateur /> </ id> <propriété name = "name" colonnes = "name" type = "Java.Lang. name = "manufacture" colonnes = "manufacture" type = "java.lang.string" /> <propriété name = "regioncode" colonnes = "régioncode" type = "java.lang.string" /> </ class>
Fichiers de mappage très ordinaires, aucune différence par rapport aux précédents.
Écrivons directement une méthode de test:
public void testSelect () {query query = session.createery ("from titre"); List list = query.list (); Iterator iter = list.iterator (); while (iter.hasnext ()) {System.out.println ("name:" + (((TITEM) iter.next ()). getName ()));}} Notez que nous utilisons ici la classe TitEm, pas la classe de mots spécifique. Ici, il recherchera automatiquement les sous-classes héritées de la classe TiTEM et trouvera tous les résultats. Cela implique un polymorphisme. La balise de classe a le polymorphisme de propriété, et sa valeur par défaut est implicite, ce qui signifie que le résultat peut être interrogé sans spécifier de nom. S'il est explicite, cela signifie que vous devez spécifier un nom de classe spécifique avant de pouvoir trouver le résultat de ce type.
2) Dans l'exemple précédent, nous avons utilisé trois fichiers de mappage. Lorsque nous devons modifier, nous devons modifier trois fichiers de mappage, ce qui n'est pas possible pour les grands projets. De plus, chaque tableau a des champs correspondants pour la classe principale correspondante, qui est redondante. Nous avons donc la méthode suivante.
La classe d'entité est toujours la même que dans 1). Nous modifions le fichier de mappage de trois en un et conservons uniquement le fichier de mappage TiTEM. Mais nous devons apporter des modifications correspondantes, et le contenu est maintenant le suivant:
<class name = "titem" table = "item" polymorphism = "explicit"> <id name = "id" chronn = "id" type = "java.lang.integer"> <générateur /> </ id> <propriété name = "name" chronn = "name" type = "manufacture" Type = "java.lang.string" /> <joint-subclass name = "tBook" table = "tBook"> <key column = "id" /> <propriété name = "pageCount" colonnel = "pageCount" type = "java.lang.integer" /> </ joinbine-subclass> <joint-subclass name = "Tdvd" table = "TDVD> <join-subclass name =" Tdvd "Table =" TDVD> colonnes = "id" /> <propriété name = "regioncode" chronn = "regioncode" type = "java.lang.string" /> </ join-subclass> </ class>
Ici, nous n'avons qu'un fichier de mappage, mais il y a une balise de sous-classe jointe, ce qui indique que cette classe hérite de la classe actuelle, <Key> indique la clé principale de la sous-table. Ici, la sous-table fait référence aux deux tables correspondant aux sous-classes, TBOOK et TDVD. Seuls les champs de la sous-table sont spécifiés dans la propriété.
De cette façon, le tableau généré après notre course est le suivant:
Le tableau correspondant aux deux sous-classes n'est que les champs que nous spécifions via la propriété. Cela évite plusieurs champs dans le tableau, de sorte que le tableau des mots maintient uniquement ses champs séparés. Lorsque la classe d'élément change, il n'est pas nécessaire de faire trop de modifications.
3) Apprenons une autre méthode pour implémenter la conception hiérarchique, qui est réalisée en mettant des drapeaux dans la table. Dans le fichier de mappage Hibernate, nous l'implémentons via la balise Descriminator.
Sans plus tarder, jetons un coup d'œil à l'exemple:
Nous avons modifié le fichier de mappage du titre d'hier à:
<class name = "titem" table = "item" polymorphism = "explicit"> <id name = "id" column = "id" type = "java.lang.integer"> <générateur /> </ id> <discriminator colonnen = "catégorie" type = "java.lang.string" /> <propriété name = "name" colonnel = "name" type = "java.lang. />" name "colonnes =" nom " <propriété name = "manufacture" colonnes = "manufacture" type = "java.lang.string" /> </ class>
En voyant le milieu, nous avons ajouté une étiquette de discriminatrice, qui montre quel champ sur les deux sous-classes se distingue.
<subclass name = "tBook" Discriminator-Value = "1"> <Property Name = "PageCount" Column = "PageCount" /> </ Subclass> <Subclass Name = "TDVD" Discriminator-Value = "2"> <Propriété Name = "RegionCode" Column = "RegionCode" /> </sublass>
Nous voyons ces deux paragraphes, qui indiquent que lorsque la valeur du champ spécifié par le discriminateur est 1, elle indique qu'il s'agit d'une classe TBOOK et que PageCount a une valeur; Lorsque la valeur du champ spécifié par le discriminateur est 2, elle indique qu'il s'agit d'une classe TDVD et que le code région a une valeur.
De cette façon, nous n'avons qu'à utiliser un seul tableau, ce qui indique la relation entre eux et plusieurs classes. Notez que cette méthode n'est pas bonne pour trop de sous-classes. Il provoquera trop de champs dans le tableau principal et provoquera certains inconvénients de conception.