Patrón de repositorio: ¿cómo entenderlo y cómo funciona con entidades "complejas"?
Me está costando entender el patrón de repositorio.
Hay muchas opiniones sobre ese tema como enPatrón de repositorio bien hecho pero también otras cosas comoRepository es el nuevo Singleton o de nuevo como enNo use DAO use Repository o simplemente tomarSpring JPA Data + Hibernate + MySQL + MAVEN donde de alguna manera un repositorio parece ser el mismo que un objeto DAO.
Me estoy cansando de leer estas cosas ya que, en mi opinión, esto no puede ser tan difícil como se muestra en muchos artículos.
Lo veo así: parece que lo que quiero es algo como esto:
------------------------------------------------------------------------
| Server |
------------------------------------------------------------------------
| | | |
Client <-|-> Service Layer <-|-> Repository Layer <-|-> ORM / Database Layer |
| | | |
------------------------------------------------------------------------
losService Layer
toma*DTO
objetos y los pasa a laRepository Layer
que básicamente no es más que "el chico" que sabecómo Se puede almacenar una entidad.
Por ejemplo, suponga que tiene una composición de algunas herramientas (tenga en cuenta que esto es solo un pseudocódigo)
@Entity
class ToolSet {
@Id
public Long id;
@OneToOne
public Tool tool1;
@OneToOne
public Tool tool2;
}
@Entity
class Tool {
@Id
public Long id;
@OneToMany
public ToolDescription toolDescription;
}
@Entity
class ToolDescription {
@Id
public Long id;
@NotNull
@OneToOne
public Language language
public String name;
public String details;
}
Lo que no entiendo es la parte donde obtengo unToolSetDTO
objeto del cliente.
Como lo entendí hasta ahora, podría escribir unToolSetRepository
con un métodoToolSetRepository.save(ToolSetDTO toolSetDto)
ese "sabe guardar" unaToolSetDTO
. Pero casi todos los tutoriales no pasan el*DTO
pero elEntity
en lugar.
Lo que me molesta aquí es que si tomas miToolSet
ejemplo de arriba tendría que hacer los siguientes pasos:
toolSetDto
y verifica si nonull
Para cadatool*Dto
propiedad detoolSetDto
a) Si tiene una identificación válida, entonces convierta de
DTO
aEntity
de lo contrario, cree una nueva entrada en la base de datossi)
toolDescriptionDto
y convertirlo / guardarlo en la base de datos o crear una nueva entradaDespués de verificar las instancias anterioresToolSet
(entidad) y configúrelo para persistirlo en la base de datosTodo esto es demasiado complejo para simplemente dejar que la función de servicio (interfaz para el cliente) se encargue de esto.
Lo que estaba pensando era crear p. Ej. unaToolSetRepository
pero la pregunta aquí es
ToolSet
entidad objeto o utiliza unDTO
¿objeto?En cualquier caso: es el*Repository
permitidoutilizar otros objetos de repositorio? Como cuando quiero ahorrarToolSet
pero tengo que almacenarTool
yToolDescription
primero, usaríaToolRepository
yToolDescriptionRepository
dentroToolSetRepository
?Si es así: ¿por qué no rompe el patrón de repositorio? Si este patrón es básicamente una capa entre el servicio y mi marco ORM, simplemente no se "siente bien" agregar dependencias a otros
*Repository
clases debido a razones de dependencia.No sé por qué no puedo entender esto. No suenaese complicado pero todavía hay ayuda por ahí comoSpring Data
. Otra cosa que me molesta, ya que realmente no veo cómo esto hacecualquier cosa más fácil. Especialmente porque ya estoy usando Hibernate, no veo el beneficio (pero tal vez esa es otra pregunta).
Entonces ... Sé que esta es una pregunta larga, pero ya dediqué unos días de investigación. Ya existe un código en el que estoy trabajando en este momento que comienza a convertirse en un desastre porque simplemente no puedo ver a través de este patrón.
Espero que alguien pueda darme una visión más amplia que la mayoría de los artículos y tutoriales que no van más allá de implementar un ejemplo muy simple de un Patrón de repositorio.