Duda estructura DTO

desu #1 Oct '19

Que os parece mejor?

Opción A

sealed class Category(val type: String) {
    data class A(val description: Id, val value: Int) : Category("A")
    data class B(val description: Id) : Category("B")
    data class C(val value: Int) : Category("C")
}

Produce:

"category": {
  "type": "A"
  "description": "description of A"
  "value": 4
}

Opción B

sealed class Category() {
    data class A(val description: Id, val value: Int) : Category()
    data class B(val description: Id) : Category()
    data class C(val value: Int) : Category()
}

Produce:

"category": {
  "description": "description of A"
  "value": 4
}

Ponerse siempre el type a pesar de ser redundante?

Wei-Yu #2 Oct '19

pero pa qué quieres el dto, es relevante esa información para el consumidor?

1 respuesta

desu #3 Oct '19

#2 El consumidor a priori no sabe la categoria. El consumidor pide objetos, estos objetos tienen 3 posibles categorías.

Otra duda sobre graphql, se puede pedir un valor de A? Pido los objetos y si son de esa categoría coge el field.

Estoy desde el móvil no se si se entiende.

Wei-Yu #4 Oct '19

pero es relevante o no? es lo único importante; el consumidor necesita de esa información para algo?

1 respuesta

desu #5 Oct '19

#4 necesitas poder distinguir, no es relevante.

Mi duda es si los clientes en angular por ejemplo saben hacer el cast automático. Porque puede darse el caso que haya colision de tipos, entonces hará falta el campo.

Si category A y category B, tienen los mismos tipos de campos y mismos nombres no podrán distinguir.

Quiero saber como se trata esto y luego lo de graphql me ha surgido.

afhn #6 Oct '19 Guardia Imperial

Para k quieres saber eso jaja saludos

1 1 respuesta

Wei-Yu #7 Oct '19

quizás sea algo que ocurra en alguna situación pero normalmente si tienes dos representaciones distintas tienes dos accesos distintos; no necesitas esa mutabilidad para nada y en caso de necesitarla expones el tipo y ya

un dto o un dao o cualquier otro invento similar no es más que una abstracción conceptual que se reduce a delimitar una estructura de datos que sea relevante para el contexto en el que la necesitas... por ejemplo, no puedes tipar una request y devolver el mismo tipo una vez se procese, porque aunque sean parecidos e incluso coincidan en todo son conceptualmente cosas disjuntas, sólo coincide que en ese contexto transportan la misma estructura de datos

1 1 respuesta

desu #8 Oct '19

#7 no tienes dos accesos. Solo tienes el acceso a objeto, categoría es un campo.

Como expones el tipo?

El dto es para exponer en una api. Tengo un end point que es get objects, los objects tienen categorías.

desu #9 Oct '19

#6 pues me ha parecido un debate curioso, sobre cómo se hace en graphql y cómo se hará cuando json muera.

Json se está quedando bastante atrás y he leído que mucha gente lo odia porque no expresa los tipos fácilmente

La raíz del problema es la falta de expresividad del json. También pasa con csv en datascience. La librería de pandas es una guarrada xd

1 respuesta

afhn #10 Oct '19 Guardia Imperial

#9 y a mí por qué me cuentas tu vida?

1 respuesta

B

[Borrado] #11 Oct '19

#10 a trolear a troleandia, aquí venimos a aprender de DTOs

2 2 respuestas

desu #12 Oct '19

#11 xd Yo es que no tengo ni idea de web y hoy estaba haciendo una api sencilla y me ha surgido la duda.

Tengo esto:

Object {
  category: Category
}

Y

Category = A | B | C

Como lo haceis?

afhn #13 Oct '19 Guardia Imperial

#11 de desu? Pero si ni siquiera se sabe las siglas, va a enseñar sobre dtos xdd

1 respuesta

Wei-Yu #14 Oct '19

si el tipo es relevante

{
"_obj": 
  {
    "_type": __
    "payload": { }
  }
}

pero si pusieses un ejemplo real sería más fácil de hablar porque en un principio si lo que tienes son modelos intercambiables lo que tendrías es un mal diseño

1 1 respuesta

B

[Borrado] #15 Oct '19

#13 yo no sé ni en qué lenguaje está trabajando

2 3 respuestas

larkkkattack #16 Oct '19

Punchline mucho, pero ya te digo yo que estructura ninguna. No te quepa duda

2

desu #17 Oct '19

#15 Produzco y consumo JSONs.

#14 Podría tener un tipo Objeto, y luego ObjetoA, ObjetoB, ObjetoC. SIn tener Category como campo y cada objeto tendría campos distintos.

Pero de nuevo, al mandar el JSON tendría que poner un campo "type" para poder parsear no?

1 respuesta

afhn #18 Oct '19 Guardia Imperial

#15 ni idea, pero lo que quiere hacer lo hago yo en 5 minutos. Demasiada programación funcional.

1 respuesta

desu #19 Oct '19

#18 No consiste en hacer o no. Consiste en como hacerlo lo mejor posible y explorar los limites de json / jackson / gson / graphql.

1 respuesta

afhn #20 Oct '19 Guardia Imperial

#19 no te flipas tío que es sólo un puto dto.

Ranthas #21 Oct '19

#17

#17desu:
Pero de nuevo, al mandar el JSON tendría que poner un campo "type" para poder parsear no?

El cliente al pedir a tu API que le sirva el JSON, ya debe saber que le va a venir de vuelta y como mapear la respuesta al modelo adecuado. No hay necesidad de parsear la respuesta para saber a que modelo debe llamar.

Es que no termino de saber cual es tu duda

1 respuesta

desu #22 Oct '19

#21 Como sabe mappear al modelo adecuado?

2 respuestas

afhn #23 Oct '19 Guardia Imperial

#22 si utilizas los componentes adecuados y una sintaxis concurrente, se hace sólo.

2 respuestas

Wei-Yu #24 Oct '19

porque cuando preguntas a alguien por algo, sabes por lo que estás preguntando

me recuerdas al yayo del timecube xd

si utilizas los componentes adecuados y una sintaxis concurrente, se hace sólo.

pero qué cojones xdddd

1 2 respuestas

afhn #25 Oct '19 Guardia Imperial

ya uno no puede ni inventarse cosas.

Ranthas #26 Oct '19

#22 Nos vamos acercando. Si tu cliente no sabe mapear la respuesta, ¿sabe lo que está pidiendo? Si tu DTO es tan abstracto que puede matchear con distintos modelos de tu cliente, es un mal diseño.

No se trata de emplear estructuras ultra-eficientes que te cubran el 100% de todos los posibles casos del planeta. Se trata de crear las estructuras necesarias para poder comunicarte con éxito con tus clientes. Si tu cliente solo maneja objetos "Ordenador" con categorias "Portatil" y "Sobremesa", pues que tu api devuelva objetos "Ordenador" con categorias "Portatil" y "Sobremesa". No hay necesidad de abstraerse más.

Ya nos cuentas.

#23 Me da que no te estás enterando de nada.

#24 sintaxis concurrente, que no te pispas pixelito rosado

2 respuestas

desu #27 Oct '19

#23 Si tienes una clase abstracta y dos subclases con los mismos campos como los distingues?

Quiero ver el código de como interpreta el JSON.

https://www.ecma-international.org/ecma-262/6.0/#sec-parseint-string-radix

Esto pero para objetos. No encuentro la docu.

En otros formatos te puedes saltar la etiqueta para poder saber que parsear?

2 respuestas

afhn #28 Oct '19 Guardia Imperial

#26 sólo estoy haciendo tiempo.

#27 npi, es que todavía sigo sin entender qué buscas xddd.

Ranthas #29 Oct '19

#27desu:
Si tienes una clase abstracta y dos subclases con los mismos campos como los distingues?

Sin más datos....¿por qué esos atributos comunes no están en la clase abstracta/padre? Si esos atributos no corresponden al dominio de esa clase abstracta, ¿por qué no creas una nueva clase que herede de la abstracta y cuyo dominio si cubra esos atributos? Luego tus otras dos subclases pueden heredar de esta nueva.

desu #30 Oct '19

#26 Mal diseño? Puede. Veamos sobre tu ejemplo:

Tengo una clase Ordernador, los ordenadores pueden ser o bien Portatil o bien Sobremesa. Yo devuelvo una lista de ordenadores.
Si es portatil tiene unos campos.
Si es sobremesa tiene otros campos.

El cliente solo sabe que recibe Ordenador.

Si mi cliente en js por ejemplo tiene la interficie Ordenador. Tiene sobremesa y portatil que la extiende. Imagino que el parser es lo suficientemente listo como para probar y encontrar el que funcione. Así funciona en otros frameworks como pandas que he comentado. Imagino que será lo mismo.

Ahora si tenemos a nivel de tipo los mismos tipos para portatil y sobremesa ya no podemos distinguirlos. Por tanto tu respuesta es crear alias/tipos más acoplados al dominio para que se distingan ambos o bien añadir una etiqueta/campo que sea "tipo". La última opción es lo que he comentado.

Mi primera duda es si sabe hacer esto:
"Si mi cliente en js por ejemplo tiene la interficie Ordenador. Tiene sobremesa y portatil que la extiende. Imagino que el parser es lo suficientemente listo como para probar y encontrar el que funcione. Así funciona en otros frameworks como pandas que he comentado. Imagino que será lo mismo."

Tu respuesta me convence, gracias.

1 respuesta

Duda estructura DTO

Usuarios habituales

Tags