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*DTOobjetos 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:

TomartoolSetDto y verifica si nonullPara cadatool*Dto propiedad detoolSetDto
a) Si tiene una identificación válida, entonces convierta deDTO aEntity de lo contrario, cree una nueva entrada en la base de datos
si)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 datos

Todo 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

¿Se necesita unToolSet 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.

Respuestas a la pregunta(1)

Su respuesta a la pregunta