Buenas noches, Habr.
Este artículo es un intento de facilitar la búsqueda de personas que comienzan en hibernación y se enfrentan a la misma pregunta que yo, a saber,
cómo escribir correctamente en esta herramienta . (Esto será especialmente útil para los programadores que vienen a Java desde lenguajes de tipo débil). No habrá código, habrá principios básicos sobre cómo utilizar esta tecnología de manera productiva. Todo lo que está escrito debajo del corte es mi IMHO, no reclamando la única solución posible al problema.
Entonces
Inmediatamente haga una reserva de que mi experiencia fue con
Spring Data JPA .
Dado que Hibernate es un marco empresarial, es difícil encontrar ejemplos de código que sean más profundos que el CRUD normal. Este hecho complica seriamente la comprensión de cómo escribir en Hiber, cómo los desarrolladores del marco se imaginaron un buen código; como resultado, tuve que pensar en este problema yo mismo. Estoy seguro de que no estoy solo.
@ @
Lo primero que puede notar es que no hay una base de datos como abstracción. En hibernación, se ha hecho todo lo posible para obtener un control total sobre la base de datos en el código (puede buscar en Google Entity Management). Su base de datos son objetos de dominio que realizan la función de almacenamiento casi estúpido. De ahí una regla importante: no los use para nada más que para almacenamiento. No deben realizar las funciones de un DTO que acepte la entrada del usuario, y no deben servir como pantalla durante la serialización. Tienen patas.
Increíble pero ciertoEn general, es sorprendente que no haya visto en el segmento educativo de Internet (incluido el inglés) un ejemplo del uso de clases adicionales para la serialización, por ejemplo, en json. ¿Quién dijo que si tiene un servicio REST, entonces no tiene que preocuparse por las clases de visualización?)
Sí, y no para REST, la intuición sugiere que en un buen tono, le dará al cliente solo el conjunto de datos que necesita, mientras que todos los datos están listos (y no tuvieron que llamar a los captadores del cliente para una inicialización diferida).
@ @
Esto implica la siguiente regla: no deberían preocuparse por el formato de uso. Ya sea que necesitemos una lista de productos (donde solo estará el nombre y la descripción) o una página del producto (con fotos y reseñas), el cliente recibirá en un caso una
List de
SimpleProductViewer (id, name, description) , y en el otro
ExtendedProductViewer (id, name, description, List(photos), List(reviews), rating) , que se generará en los métodos de la clase
ProductService y usará las clases de dominio
solo como fuente de datos.
Lo mismo con la entrada. Esto es Java, aquí está bien hacer DTO con diferentes campos para cada caso :)
Como ejemplo, aumentaré la base de clases para el dominio del Producto trillado. Lo que ya tenemos:
- Producto (dominio)
- Visor (clases para la visualización de información del cliente, puede ser cualquier número)
- Dto (las clases para obtener información también pueden ser cualquier número)
- Repositorio (para recibir datos)
- Servicio (o Administrador): un cuadro negro para la lógica empresarial no controlada, que combina todos los puntos anteriores.
@ @
Me parece (parece) que Java Enterprise no está muy optimizado (esto se puede ver ya a pedido de hibernate y el hecho mismo de que OOP (hibernate) se ha hecho cargo de la manta para administrar entidades de bases de datos). Por lo tanto, creo que lo principal en este contexto es la correspondencia del código con las ideas de los desarrolladores del marco, y no la estrategia óptima.
@ @
Si observa los dominios de hibernación de esta manera (solo almacenamiento de datos),
@ManyToOne parece ser un mecanismo que no se usa con tanta frecuencia y se aplica solo a tablas completamente dependientes: imágenes, reseñas, comentarios. En principio, esto es normal; en mi opinión, no es necesario extender su efecto a las tablas principales de su base de datos.
Resumiendo
- Utilice el dominio solo para el almacenamiento de datos, es deseable que las propiedades de la clase estén contenidas en la tabla de la base de datos de destino, es decir, no hay nada superfluo (dictado por la lógica empresarial).
- No es necesario intentar expandir el dominio: amplíe las clases de visualización y use las clases de dominio solo como proveedor de datos.
- No tenga miedo de producir el mismo tipo de clases: la comprensión y la flexibilidad de uso son más importantes. Lo máximo que se puede hacer para reducir la cantidad de código es heredarlos del dominio.
- No persigas la optimización. Para los niños de Java esto no es importante, aunque, por supuesto, todo depende del contexto.
Algo asi.