Exponer modelos de dominio sobre API

8

Estoy creando una API RESTful simple para una aplicación basada en la web en la que estoy trabajando, y me pregunto cuál es la mejor manera de exponer mis modelos de dominio.

Digamos que tengo una clase de usuario y quiero proporcionar una respuesta JSON con las diversas propiedades del usuario. Obviamente, no quiero exponer públicamente todas las propiedades de mi modelo (cosas como DateCreated, PasswordHash, etc.) debido a problemas de seguridad y ancho de banda.

Leí en Data Transfer Objects y me pregunto si este es el camino a seguir. Si estoy en lo cierto, podría pasar, por ejemplo, un modelo de Usuario a mi DTO de Usuario y asegurarme de que dicho DTO solo permita la exposición de las propiedades del Usuario que elijo (lo que también ayudaría a desacoplar mis modelos de mi API pública).

¿Es adecuada esta solución o hay mejores formas de hacerlo?

Gracias.

language-agnostic api domain-model

— James
fuente

1

"Estoy construyendo una API pública simple " y "Obviamente no quiero exponer públicamente cada propiedad" no tiene sentido para mí, ¿podría aclarar qué quiere decir?

— Uooo

He editado mi pregunta para proporcionar más claridad, pero esencialmente lo que quiero decir es que mi objeto Usuario tiene algunas propiedades como Contraseña y FechaCreada que no deberían mostrarse en la representación JSON del Usuario, pero la mayoría de los otros datos de usuario Deberia estar disponible. Me pregunto si los DTO pueden ayudarme a separar las propiedades disponibles de las que no están disponibles.

— James

6

Esa es exactamente una de las razones por las que existen DTO.

La desventaja aquí es que agregar DTO hace que su implementación sea un poco más compleja y, por lo tanto, propensa a errores, como una falta de coincidencia en la asignación del objeto de dominio a un DTO. ¡Usa pruebas unitarias para esto!

Otra cosa que podría hacer con su DTO y que suele pasarse por alto en los servicios RESTful es tratar los datos de hipertexto para referencias, objetos anidados y posibles operaciones.

Consulte PoEAA de Martin Fowler: "[...] vale la pena mencionar que otra ventaja es encapsular el mecanismo de serialización para transferir datos a través del cable. Al encapsular la serialización de esta manera, los DTO mantienen esta lógica fuera del resto del código y también proporcionar un punto claro para cambiar la serialización si lo desea ".

http://martinfowler.com/eaaCatalog/dataTransferObject.html

TL; DR: Me gusta la idea de separar las preocupaciones de la lógica de dominio y el "cableado RESTful" a través de DTOS, aunque introduciendo un diseño más complejo.

— viniciushana
fuente

1

¡Lo pensé mucho pero solo quería aclarar eso! Al menos para mi situación, creo que los beneficios superan a los contras. ¡Gracias por tu respuesta!

— James

suponiendo que su código de back-end esté fuertemente tipado, la complejidad incurrida es compensada por la verificación del tipo de tiempo de compilación. Las asignaciones de dto.setProp (entity.getProp) comenzarán a fallar al compilarse.

— Jason

3

Aunque no es la intención principal de los Objetos de transferencia de datos , los DTO se pueden usar para satisfacer esta preocupación de manera similar a la porción de datos de un Modelo de presentación .

Como se ha señalado, esto puede inflar su diseño y algo tan simple como un campo agregado puede requerir cambios para burbujear a través de las capas adicionales. Debido a esto, es aconsejable ver si puede proporcionar metadatos para describir la serialización del objeto . En muchos idiomas, esto toma la forma de anotaciones especializadas que se pueden aplicar a los objetos de su dominio para evitar la tediosa traducción a DTO. Los paquetes como Jackson ( mediante el uso de Mixins ) a menudo llevan esta idea un poco más lejos para separar completamente sus metadatos de su modelo de dominio.

— smp7d
fuente