Análisis en profundidad del mapeo de asociación uno a uno en el marco Hibernate de Java

Como marco de ORM, Hibernate también debe satisfacer nuestras necesidades para implementar la asociación entre tablas. La implementación de Hibernate en el método de asociación es muy simple. Echemos un vistazo al enfoque uno a uno:
Sin más preámbulos, solo subamos el código:
Dos clases de entidad, Tuser y TPassport:

 Public Class Tuser implementa serializable {privado estático final Long SerialVersionUid = 1L; ID privado int; edad privada int; nombre de cadena privada; Pasaporte privado TPassport; // omitir el método get/set} clase pública tpassport implementa serializable {private static final long serialversionUid = 1l; ID privado int; serie de cadena privada; privado int expirado; Usuario privado Tuser; // omitir el método get/set}

Echemos un vistazo a las diferencias entre los archivos de mapeo:

 <hibernate-mapping paquete = "org.hibernate.tutorial.domain4"> <class name = "tuser" table = "user4"> <id name = "id" columna = "id"> <generador/> </d> <propiedad name = "name" type = "java.lang.string" columna = "name"/> <name de propiedad = "edad" type = "java.lang.lang.lang.lang.lang.lang" columna = "Age"/> <One-One Name = "Passport" cascade = "all" outer-join = "true"/> </class> </hibernate-mapping>

Aquí vemos una nueva etiqueta, uno a uno, que muestra que la clase actual y la clase correspondiente son uno a uno, y la cascada es una relación en cascada. Todo indica que la cascada se realiza en cualquier caso, es decir, cuando funcionan en la clase Tuser, TPassport también realizará las operaciones correspondientes. La unión externa se refiere a si se debe usar la declaración de unión externa.
Veamos otro archivo de asignación de tpassport:

 <hibernate-mapping paquete = "org.hibernate.tutorial.domain4"> <class name = "tpassport" table = "pasapport4"> <id name = "id" column = "id"> <generator> <param name = "propiedad"> user </param> </generator> </id> <name de propiedad = "serial" type = "java.lang.string" columna "columna" seroat " name = "expiry" type = "java.lang.integer" columna = "expiry"/> <One-a one name = "user" restringed = "true"/> </class> </hibernate-mapping>

Aquí nos centramos en el valor de clase del generador. Indica la clave extranjera de referencia para extranjeros, y qué referencia es especificada por Param, que indica la ID de la clase de usuario de referencia. Hay una propiedad restringida adicional en la etiqueta uno a uno, que le dice a Hibernate que existe una restricción de clave extranjera en la clase actual, es decir, la ID de la clase actual se genera en función de la ID del tusor.
Cargamos directamente la clase de prueba. Esta vez, la clase de prueba no usó Junit, pero vino directamente con el método principal:

 public static void main (string [] args) {Configuration cfg = new Configuration (). Configuración (); SessionFactory sessionFactory = cfg.BuildSessionFactory (); Sesión session = sessionFactory.opensession (); session.BeginTransaction (); Tuser user = new Tuser (); user.setage (20); user.setName ("Shuntest"); Tpassport pasaporte = new tpassport (); pasaporte.setExpiry (20); pasaporte. Setserial ("123123123"); Passport.SetUser (usuario); user.setPassport (pasaporte); session.save (usuario); session.getTransaction (). Commit (); }

El código es muy simple, por lo que no hablaré de ello. Veamoslo principalmente aquí:

 session.save (usuario);

¿Por qué solo llamamos a una salvación aquí? La razón es que la propiedad Cascade en nuestro archivo de asignación de tusores se establece en todos, lo que significa que cuando guardamos, actualizamos, eliminamos, etc. En el Tuser, TPassport también realizará las operaciones correspondientes, por lo que no necesitamos escribir session.save (pasaporte). Vemos el fondo:

 Hibernate: inserte en los valores de usuario4 (nombre, edad) (?,?) Hibernate: inserte en pasaporte4 (serial, vencimiento, id) valores (?,?)

Hibernate: imprime dos declaraciones, demostrando que Hibernate ha hecho este trabajo por nosotros.


Tomemos otra clase de prueba y consulta de prueba:

 public static void main (string [] args) {Configuration cfg = new Configuration (). Configuración (); SessionFactory sessionFactory = cfg.BuildSessionFactory (); Sesión session = sessionFactory.opensession (); Tuser user = (Tuser) Session.Load (Tuser.Class, New Integer (3)); System.out.println (user.getName ()+":"+user.getPassport (). GetSerial ()); }

Aquí consultamos la clase Tuser y obtenemos el objeto tpassport.
Podemos ver que la declaración SQL de Hibernate es:
La copia del código es la siguiente:
Hibernar:
seleccione tuser0_.id como id0_1_, tuser0_.name as name0_1_, tuser0_.age como age0_1_, tpassport1_.id como id1_0_, tpassport1_.serial como serial1_0_, tpassport1_.expiry como expiry1_0_ de user4 tuser0_ izquierda exputin ibinter una exterter tuser0_.id = tpassport1_.id donde tuser0_.id =?

Vemos a la izquierda que se une a la declaración, porque establecemos externo-join = "verdadero" en uno a uno. Intentamos cambiarlo a falso. La declaración SQL es la siguiente:
La copia del código es la siguiente:
Hibernar:
Seleccione Tuser0_.id como id0_0_, tuser0_.name as name0_0_, tuser0_.age como AGE0_0_ de user4 tuser0_ donde tuser0_.id =? Hibernate:
Seleccione tpassport0_.id como id1_0_, tpassport0_.serial como serial1_0_, tpassport0_.expiry como expiry1_0_ desde pasaporte4 tpassport0_ donde tpassport0_.id =?

Ahora lo hemos dividido en dos elementos para verificarlo, y luego lo encontramos basado en la identificación que se encuentra en el primer elemento y luego en el segundo elemento.

Tal vez muchas personas preguntan por qué no usan Tpassport para descubrir los columnas durante las pruebas. De hecho, también es posible, porque son una relación uno a uno, y todos los que la controlan serán lo mismo.

Asociación de Clave Exterior
Ahora echemos un vistazo a las asociaciones uno a uno que hacen asociaciones a través de claves extranjeras.
Sigue siendo lo mismo que el ejemplo: escribimos dos clases de entidad, Tgroup y Tuser

 La clase pública TGROUP implementa serializable {privado estático final largo serialVersionUid = 1l; ID privado int; nombre de cadena privada; Usuario privado Tuser; // omitir el método get/set} columer de clase pública implementa serializable {private static final long serialversionUid = 1l; ID privado int; edad privada int; nombre de cadena privada; Grupo privado TGROUP; // omitir el método get/set}

Después de que se termine la clase de entidad, echemos un vistazo al archivo de mapeo:

 <hibernate-mapping paquete = "org.hibernate.tutorial.domain5"> <class name = "tuser" table = "user5"> <id name = "id" column = "id"> <generador/> </d> <propiedad name = "name" type = "java.lang.string" column = "name"/> <name de propiedad = "edad" type = "java.lang.lang.lang.lang.lang.lang" columna = "Age"/> <Many-To-One Name = "Group" Column = "Group_id" unique = "True"/> </class> </hibernate-mapping>

Aquí vemos que la etiqueta de muchos a uno se usa en lugar de uno a uno. ¿Por qué?
No le presté mucha atención cuando lo usé antes. De todos modos, solo necesito usarlo. Pero después de leer el libro de Xia Xin esta vez, finalmente entendí que, de hecho, esta forma de asociación a través de claves extranjeras es solo una forma especial de muchos a uno. Lo limitamos a través de unique = "verdadero" que debe tener solo una, es decir, una correlación individual.
A continuación, echemos un vistazo al archivo de mapeo de TGroup:

 <hibernate-mapping paquete = "org.hibernate.tutorial.domain5"> <class name = "tGroup" table = "group5"> <id name = "id" column = "id"> <generador/> </d> <propiedad name = "name" type = "java.lang.string" column = "name"/> <One to-one name = "usser" ree "name" group " </hibernado mapeo>

Aquí, tenga en cuenta que usamos uno a uno nuevamente, lo que indica que la entidad y el tusor actuales son uno a uno. Aquí, no usamos muchos a uno, sino que especificamos qué atributo en la entidad Tuser para asociar la clase TGROUP actual. Aquí especificamos que Tuser está asociado con Tuser a través de atributos de grupo. propiedad-ref especifica qué propiedad asociar.
Veamos la clase de prueba a continuación:

 clase pública HibernateTest {public static void main (string [] args) {Configuration cfg = new Configuration (). Configuración (); SessionFactory sessionFactory = cfg.BuildSessionFactory (); Sesión session = sessionFactory.opensession (); session.BeginTransaction (); TGROUP GROUP = new TGroup (); Group.SetName ("TestGroup"); Tuser user = new Tuser (); user.setage (23); user.setName ("prueba"); user.setGroup (grupo); Group.SetUser (usuario); session.save (grupo); session.save (usuario); session.getTransaction (). Commit (); session.close (); }}

Tenga en cuenta que nuestro código debe guardar dos veces esta vez porque tienen correspondencias correspondientes entre sí. Guardar solo uno no causará ninguna operación en la otra. Por lo tanto, necesitamos llamar a la operación guardada dos veces. Finalmente haz una presentación.
Hibernate imprime la declaración:

 Hibernate: inserte en los valores del grupo5 (nombre) (?) Hibernate: Insertar en los valores de usuario5 (nombre, edad, grupo_id) (?,?,?)

Esto significa que almacenamos correctamente dos valores de objetos.

Escribimos una clase de prueba adicional para consultar:

 public static void main (string [] args) {Configuration cfg = new Configuration (). Configuración (); SessionFactory sessionFactory = cfg.BuildSessionFactory (); Sesión session = sessionFactory.opensession (); Tuser user = (Tuser) Session.Load (Tuser.Class, New Integer (1)); System.out.println ("De user Get Group:"+user.getgroup (). GetName ()); TGROUP GROUP = (TGROUP) Session.Load (tGroup.class, nuevo entero (1)); System.out.println ("De Group Get User:" + Group.getuser (). GetName ()); session.close (); }

Ambos podemos obtener el resultado correcto, que muestra que podemos eliminar los valores del otro a través de dos objetos, logrando nuestro objetivo.
El TGroup y el Tuser utilizados en este ejemplo son solo ejemplos. De hecho, los usuarios en la vida real generalmente corresponden a múltiples grupos.