Analyse approfondie de la cartographie d'association individuelle dans le cadre d'hibernate de Java

En tant que cadre ORM, Hibernate doit également répondre à nos besoins pour mettre en œuvre l'association entre les tables. La mise en œuvre de l'hibernate dans la méthode d'association est très simple. Jetons un coup d'œil à l'approche en tête-à-tête:
Sans plus tarder, téléchargeons simplement le code:
Deux cours d'entités, TUSER et TPASSPORT:

 classe publique TUSER implémente Serializable {private statique final long SerialVersionUID = 1l; INT PRIVÉ ID; Âge privé; nom de chaîne privé; Passeport tpassport privé; // OMIT Méthode Get / Set} classe publique TPassport implémente Serializable {private static final long SerialVersionUID = 1l; INT PRIVÉ ID; série de chaînes privées; Expiration privée int; Utilisateur de tus-pour-tuer privé; // omettre la méthode get / set}

Jetons un coup d'œil aux différences entre les fichiers de cartographie:

 <hibernate-mapp package = "org.hibernate.tutorial.domain4"> <class name = "tuser" table = "user4"> <id name = "id" column = "id"> <générateur /> </ id> <propriété name = "name" type = "java.lang.string" colonnel = "name" /> <propriété name = "Âge" type = "java.lang. Column = "Age" /> <un à un name = "Passport" Cascade = "All" exter-join = "true" /> </ class> </ hibernate-mapping>

Ici, nous voyons une nouvelle étiquette, un à un, qui montre que la classe actuelle et la classe correspondante sont individuelles, Cascade est une relation en cascade, tout montre que quelle que soit la situation, c'est-à-dire lorsqu'il fonctionne sur la classe TUSER, TPassport effectuera également des opérations correspondantes. La jointure extérieure fait référence à l'opportunité d'utiliser l'énoncé de jointure externe.
Regardons un autre fichier de mappage TPassport:

 <hibernate-mapp package = "org.hibernate.tutorial.domain4"> <class name = "tpassport" table = "Passport4"> <id name = "id" column = "id"> <enerator> <param name = "propriété"> user </ param> </ générateur> </ id> <propriété name = "serial" type = "Java.Lang.string" name = "expiry" type = "java.lang.integer" chronn = "expiry" /> <one-to-one name = "user" contraint = "true" /> </sclass> </ hibernate-mapping>

Ici, nous nous concentrons sur la valeur de classe du générateur. Il indique la clé étrangère de référence pour étrangère, et quelle référence est spécifiée par Param, qui indique l'ID de la classe utilisateur de référence. Il existe une propriété contrainte supplémentaire dans la balise un à un, qui indique à Hibernate qu'il existe une contrainte de clé étrangère dans la classe actuelle, c'est-à-dire que l'ID de la classe actuelle est généré en fonction de l'ID de la tusur.
Téléchargeons directement la classe de test. Cette fois, la classe de test n'a pas utilisé JUnit mais est venue directement avec la méthode principale:

 public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = cfg.BuildSessionFactory (); Session Session = SessionFactory.OpenSession (); session.begintransaction (); TUSER User = new Tuser (); user.setAGE (20); user.setName ("SHUNTEST"); TPASSPORT PASSPORT = NOUVEAU TPASSPORT (); Passport.SetExpiry (20); Passport.SetSerial ("123123123"); Passport.SetUser (utilisateur); user.setpassport (passeport); session.save (utilisateur); session.getTransaction (). commit (); }

Le code est très simple, donc je n'en parlerai pas. Regardons-le principalement ici:

 session.save (utilisateur);

Pourquoi n'appelons-nous qu'une seule sauvegarde ici? La raison en est que la propriété Cascade dans notre fichier de mappage TUSER est définie sur tous, ce qui signifie que lorsque nous enregistrons, mettons à jour, supprimons, etc. Sur le TUSER, TPassport effectuera également des opérations correspondantes, nous n'avons donc pas besoin d'écrire session.save (passeport). Nous voyons l'arrière-plan:

 HiberNate: Insérer dans User4 (nom, âge) Valeurs (? ,?) Hibernate: Insérer dans les valeurs Passport4 (série, expiry, id) (?,?)

Hibernate: il imprime deux déclarations, prouvant que Hibernate a fait ce travail pour nous.


Prenons une autre classe de test et une requête de test:

 public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = cfg.BuildSessionFactory (); Session Session = SessionFactory.OpenSession (); TUSER USER = (TUSER) Session.Load (TUSER.CLASS, NOUVEAU INTEGER (3)); System.out.println (user.getName () + ":" + user.getPassport (). GetSerial ()); }

Ici, nous interrogeons la classe TUSER et obtenons l'objet TPassport.
Nous pouvons voir que l'instruction SQL de Hibernate est:
La copie de code est la suivante:
Hiberner:
Sélectionnez tuser0_.id as id0_1_, tuser0_.name as name0_1_, tuser0_.age as agent0_1_, tpassport1_.id as id1_0_, tpassport1_.serial as serial1_0_, tpassport1_.expiry topport1_0_ de user4 tuser0_ tuser0_.id = tpassport1_.id où tuser0_.id =?

Nous voyons la direction de gauche dans l'instruction, car nous avons défini l'extérieur-join = "true" en un à un. Nous essayons de le changer en faux. L'instruction SQL est la suivante:
La copie de code est la suivante:
Hiberner:
Sélectionnez tuser0_.id comme id0_0_, tuser0_.name as name0_0_, tuser0_.age en tant qu'âge 00_0_ de user4 tuser0_ où tuser0_.id =? hibernate:
Sélectionnez TPassport0_.id AS ID1_0_, TPASSPORT0_.SERIAL AS SERIAL1_0_, TPASSPORT0_.Expiry en tant qu'EXPIRY1_0_ à partir de Passport4 TPASSPORT0_ WHERE TPASSPORT0_.ID =?

Maintenant, nous l'avons divisé en deux éléments pour le vérifier, puis l'avons trouvé en fonction de l'ID trouvé dans le premier élément, puis au deuxième élément.

Peut-être que beaucoup de gens demanderont pourquoi ils n'utilisent pas TPassport pour découvrir des tusurs pendant les tests. En fait, c'est également possible, car ils sont une relation un à un, et tous ceux qui le vérifient seront les mêmes.

Association des clés étrangères
Jetons maintenant un coup d'œil aux associations individuelles qui font des associations à travers des clés étrangères.
C'est toujours la même chose que l'exemple: nous avons écrit deux cours d'entités, Tgroup et TUSER

 La classe publique TGROUP implémente Serialisable {private statique final long SerialVersionUID = 1l; INT PRIVÉ ID; nom de chaîne privé; Utilisateur de tus-pour-tuer privé; // OMIT Méthode Get / Set} classe publique TUSER implémente Serializable {private static final long SerialVersionUID = 1l; INT PRIVÉ ID; Âge privé; nom de chaîne privé; Groupe Tgroup privé; // omettre la méthode get / set}

Une fois le cours d'entité terminé, jetons un coup d'œil au fichier de mappage:

 <hibernate-mapp package = "org.hibernate.tutorial.domain5"> <class name = "tuser" table = "user5"> <id name = "id" column = "id"> <générateur /> </ id> <propriété name = "name" type = "java.lang.string" collumn = "name" /> <propriété name = "Âge" type = "java.lang. colonnes = "age" /> <plusieurs à un nom = "groupe" chronn = "group_id" unique = "true" /> </ class> </ hibernate-mapping>

Ici, nous voyons que la balise multiple est utilisée à la place d'un à un. Pourquoi?
Je n'y ai pas accordé beaucoup d'attention lorsque je l'ai déjà utilisé. Quoi qu'il en soit, je pourrais l'utiliser. Mais après avoir lu le livre de Xia Xin cette fois, j'ai finalement compris qu'en fait, cette façon d'association à travers des clés étrangères n'est qu'un moyen spécial de plusieurs à un. Nous l'avons limité via unique = "true" qu'il ne doit en avoir qu'un, c'est-à-dire une association individuelle.
Ensuite, jetons un coup d'œil au fichier de mappage de Tgroup:

 <hibernate-mapp package = "org.hibernate.tutorial.domain5"> <class name = "tgroup" table = "group5"> <id name = "id" column = "id"> <générateur /> </ id> <propriété name = "name" type = "java.lang.string" colonne </ Hibernate-Mapping>

Ici, notez que nous utilisons à nouveau un à un, ce qui indique que l'entité actuelle et le tuser sont un à un. Ici, nous n'utilisons pas plusieurs à un, mais spécifions quel attribut dans l'entité TUSER pour associer le Tgroup de classe actuel. Ici, nous spécifions que TUSER est associé à TUSER via des attributs de groupe. Property-Ref Spécifie la propriété à associer.
Regardons la classe de test ci-dessous:

 classe publique HiberNateTest {public static void main (String [] args) {configuration cfg = new Configuration (). configure (); SessionFactory SessionFactory = cfg.BuildSessionFactory (); Session Session = SessionFactory.OpenSession (); session.begintransaction (); Groupe tgroup = new tgroup (); groupe.setName ("testgroup"); TUSER User = new Tuser (); user.setage (23); user.setName ("test"); user.setGroup (groupe); groupe.setUser (utilisateur); session.save (groupe); session.save (utilisateur); session.getTransaction (). commit (); session.close (); }}

Notez que notre code doit être enregistré deux fois cette fois car ils ont des correspondances correspondantes les uns pour les autres. En sauver un seul ne provoquera aucune opération de l'autre. Nous devons donc appeler l'opération enregistrée deux fois. Enfin, faites une soumission.
Hibernate imprime la déclaration:

 Hibernate: Insérer dans les valeurs du groupe5 (nom) (?) Hibernate: insérer dans l'utilisateur5 (nom, âge, groupe_id) valeurs (? ,?)

Cela signifie que nous avons correctement stocké deux valeurs d'objet.

Nous écrivons une classe de test supplémentaire pour interroger:

 public static void main (String [] args) {configuration cfg = new configuration (). configure (); SessionFactory SessionFactory = cfg.BuildSessionFactory (); Session Session = SessionFactory.OpenSession (); TUSER User = (tuser) session.load (tUser.class, nouvel entier (1)); System.out.println ("From User Get Group:" + user.getGroup (). GetName ()); TGROUP GROUP = (TGROUP) Session.load (tgroup.class, nouvel entier (1)); System.out.println ("From Group Get User:" + Group.getUser (). GetName ()); session.close (); }

Nous pouvons tous deux obtenir le résultat correct, ce qui montre que nous pouvons retirer les valeurs de l'autre à travers deux objets, atteignant notre objectif.
Le TGROUP et le tuser utilisés dans cet exemple ne sont que des exemples. En fait, les utilisateurs de la vie réelle correspondent généralement à plusieurs groupes.