Data Transfer Object (DTO) – Patrón de diseño

Data Transfer Object (DTO) – Patrón de diseño

Una de las problemáticas más comunes cuando desarrollamos aplicaciones, es diseñar la forma en que la información debe viajar desde la capa de servicios a las aplicaciones o capa de presentación, ya que muchas veces por desconocimiento o pereza, utilizamos las clases de entidades para retornar los datos, lo que ocasiona que retornemos más datos de los necesarios o incluso, tengamos que ir en más de una ocasión a la capa de servicios para recuperar los datos requeridos.

El patrón DTO tiene como finalidad de crear un objeto plano (POJO) con una serie de atributos que puedan ser enviados o recuperados del servidor en una sola invocación, de tal forma que un DTO puede contener información de múltiples fuentes o tablas y concentrarlas en una única clase simple.

DTO mapping
DTO mapping

En la imagen anterior podemos apreciar gráficamente como es que un DTO se conforma de una serie de atributos que puede o no, estar conformados por más de una fuente de datos. Para esto, el servidor obtiene la información de las tablas customer y address (izquierda) y realiza un mapping con el DTO (derecha). Adicional, la información puede ser pasada de un lado intacta como es el caso del id , fullName , country , address  y zipCode  o ser una derivada de más de un campo, como es el caso del fullName , el cual es la unión del firstname  y lastname .

Otra de las ventajas no tan claras en la imagen, es que nos permite omitir información que el usuario no requiere, como es el caso de password. No es solo que no lo requiere, sino que además podría ser una gran falla de seguridad está enviando los passwords, es por ello que en el DTO lo omitimos.

Características de un DTO

Si bien un DTO es simplemente un objeto plano, sí que tiene que cumplir algunas reglas para poder considerar que hemos creado un DTO correctamente implementado:

  • Solo lectura: Dado que el objetivo de un DTO es utilizarlo como un objeto de transferencia entre el cliente y el servidor, es importante evitar tener operaciones de negocio o métodos que realicen cálculos sobre los datos, es por ello que solo deberemos de tener los métodos GET y SET de los respectivos atributos del DTO.
  • Serializable: Es claro que, si los objetos tendrán que viajar por la red, deberán de poder ser serializables, pero no hablamos solamente de la clase en sí, sino que también todos los atributos que contenga el DTO deberán ser fácilmente serializables. Un error clásico en Java es, por ejemplo, crear atributos de tipo Date o Calendar para transmitir la fecha u hora, ya que estos no tienen una forma estándar para serializarse por ejemplo en Webservices o REST.

Entidades vs DTO

Un error muy frecuente entre programadores inexpertos es el hecho de utilizar las clases de Entidad para utilizarlos para la transmisión de datos entre el cliente y el servidor. Solo para entrar en contexto, las entidades son clases que representa al modelo de datos, o mapea directamente contra una tabla de la base de datos. Dicho esto, las entidades son clases que fueron diseñadas para mapear contra la base de datos, no para ser una vista para una pantalla o servicio determinado, lo que provoca que muchos de los campos no puedan ser serializables, no contengan todos los campos necesarios un servicio, ya sea que tengan de más o de menos.

El hecho de que las entidades no contengan todos los atributos necesarios o que no sean serializables trae otros problemas, como la necesidad de agregaras más atributos a las entidades con el único objetivo de poder cubrir los requerimientos de transferencia de datos, dejando de lado el verdadero propósito de la entidad, que es únicamente mapear contra la base de datos, lo que va llevando lentamente a ir creando una mezcla entre Entidad y DTO.

Introducción a los patrones de diseño - un enfoque práctico
¿Quieres aprender más patrones como este? te invito a ver mi libro de “Introducción a los patrones de diseño” un libro donde explico los principales patrones de diseño mediante ejemplos del mundo real, olvídate de aprender los ejemplos típicos de internet, como crear una pizza, animales que ladre o figuras geométricas.

DTO en el mundo real

Para comprender mejor como es que se utilizan los DTO, vamos a realizar un análisis con un ejemplo de un servicio que recupera los datos todos los datos de los clientes. Para esto, veamos como quedarían las Entidades utilizando el API de JPA de Java.

Entidad Customer

package dtopattern;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name="customers")
public class Customer {
	@Id
	@GeneratedValue(strategy= GenerationType.IDENTITY)
	private Long id;
	@Column(name="firstname")
	private String firstname;
	@Column(name="lastname")
	private String lastname;
	@Column(name="password")
	private String password;
	
	/** GET and SET */
}

Entidad Address

package dtopattern;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToMany;
import javax.persistence.Table;

@Entity
@Table(name="address")
public class Address {
	@Id
	@GeneratedValue(strategy=GenerationType.IDENTITY)
	private Long id;
	@ManyToMany()
	@JoinColumn(name="fk_customer")
	private Customer customer;
	@Column(name="country")
	private String country;
	@Column(name="address")
	private String address;
	@Column(name="zipcode")
	private String zipCode;
	
	
	/** GET and SET */
	
}

Por otro lado, tenemos el DTO que contiene los datos del cliente (Customer) y su dirección (Address).

package dtopattern;

import java.io.Serializable;

public class CustomerDTO implements Serializable{
	
	private Long id;
	private String FullName;
	private String country;
	private String Address;
	private String zipCode;
	
	
	/** GET and SET */
}

Finalmente, veamos cómo quedaría un servicio que aproveche las ventajas del patrón DTO para transmitir los datos:

package dtopattern;

import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

@Path("customers")
public class CustomerService {
	
	@GET
	@PathParam("{customerId}")
	private Response findCustomer(@PathParam("customerId") Long customerId) {
		Customer customer = customerDAO.findCustomerById(customerId); //Entity
		Address address = customerDAO.findAddressByCustomer(customerId); //Entity
		
		//Create dto
		CustomerDTO dto = new CustomerDTO();
		dto.setAddress(address.getAddress());
		dto.setCountry(address.getCountry());
		dto.setZipCode(address.getZipCode());
		dto.setFullName(customer.getFirstname() + " " + customer.getLastname());
		dto.setId(customer.getId());
		
		//Return DTO
		return Response.ok(dto, MediaType.APPLICATION_JSON).build();
	}
}

El ejemplo que acabamos de ver, corresponde a una implementación de un servicio REST utilizando el API JAX-RS de Java, el cual indica que existe un servicio GET en la url /customers/{customerID}, donde {customerId} corresponde al ID del cliente a buscar. En el servicio, realizamos la consulta del cliente y su dirección en dos pasos, para finalmente, mapear los datos de estas dos entidades en un simple DTO que será retornado.

Curso Mastering API REST con Spring boot
¿Quieres aprender a utilizar el patrón DTO dentro de un proyecto real? te invito a mi curso Mastering API REST con Spring boot donde crearemos un API completo implementando el patrón DTO.

Ponte a pensar, como le haríamos para obtener los datos del cliente y su dirección en una sola llamada al API REST sin ayuda de un DTO. Seguramente no podremos hacerlo en una sola llamada, si no que tendríamos que hacer dos consultas, una para recuperar el Cliente y otra para recuperar su dirección, o la otra alternativa y la peor de todas, sería modificar el Entidad Customer para agregar los campos que nos falte, a pesar de que la tabla no contenga esos campos.

Conclusiones

Como hemos podido demostrar, los DTO son un patrón muy efectivo para transmitir información entre un cliente y un servidor, pues permite crear estructuras de datos independientes de nuestro modelo de datos, lo que nos permite crear cuantas “vistas” sean necesarias de un conjunto de tablas u orígenes de datos. Además, nos permite controlar el formato, nombre y tipos de datos con los que transmitimos los datos para ajustarnos a un determinado requerimiento. Finalmente, si por alguna razón, el modelo de datos cambio (y con ello las entidades) el cliente no se afectará, pues seguirá recibiendo el mismo DTO.

85 thoughts to “Data Transfer Object (DTO) – Patrón de diseño”

  1. Habia leido varios articulos pero no me quedaba claro lo que es un DTO. Tu blog me ayudo entender lo que es y hace un DTO. El ejemplo de codigo me ayudo mucho. Great job!

      1. Pregunta, tal vez un poco tonta. Que tan recomendable es despachar la información desde un service, en lugar de tener un controller que se encargue de eso y a su vez utilize el service con la lógica que implementaste

        1. pues todo depende del nivel de arquitectura que quieras lograr, en aplicaciones pequeñas puede se recomendable hacerlo directamente desde el servicios para no hace un sobre ingeniería, pero si son aplicaciones muy grandes, quizás los controllers te puedan ayudar mas.

  2. Hola , una consulta, dices: “Ponte a pensar, como le haríamos para obtener los datos del cliente y su dirección en una sola llamada al API REST sin ayuda de un DTO. Seguramente no podremos hacerlo en una sola llamada, si no que tendríamos que hacer dos consultas,”

    Lo ideal no seria que la API exponga un servicio que te provea toda la data del cliente? Eso seria mas eficiente en términos de llamadas (Ya que haces solo una llamada de red) y términos de procesamiento en la DB (ya que la API haría un JOIN (Una sola consulta), y no dos)..

    1. hola Emiliano, creo que comprendiste mal el concepto, lo que quiero decir es que el DTO evita tener que hacer más llamadas al servidor, evitando como tu dices, que se hagan varias consultas en lugar de una. Sin el DTO estamos obligados a realizar varias consultas retornar toda la información, pero con el DTO podemos retornar toda la información en una sola llamada.

  3. Hola nien explicado, pero las clases Entidades son lo mismo que las clases DAO? por decir
    es lo mismo una clase llamada UserEntity vs UserDAO ? en c# se utiliza mucho la palabra Entity es correcto esta afirmación, si no lo es cúal es su diferencia ? saludos

    1. Hola Diego, en realidad son cosas diferentes, un Entidad es una clase que por lo general representa una tabla de la base de datos, es decir, por lo general tenemos una Entidad por tabla, la idea de la Entity es poder representar nuestros modelo relacional en objetos, y es allí donde entran las Entidades, por otra parte, un DAO es un patrón arquitectónico que tiene como objetivo encapsular la lógica de acceso a datos, es decir, mediante el DAO podemos consultar, guardar, actualizar o borrar. La idea del DAO es que encapsulemos la base de datos con la que estamos trabajando, de esta forma, podríamos (en teoría), cambiar de base de datos sin que el resto del sistema se ve afectado, además, el DAO trabaja con Entidades, es decir, le enviamos entidades para guardar, actualizar y borrar, y como resultado nos retorna Entidades, de esta forma, nos olvidamos del SQL o la DB NoSQL que estés utilizando.

      1. Hola OBLANCARTE, veo que el DTO lo construyes en el service consultando 2 veces a la base de datos tanto para cliente como para direccion. La consulta es porque no se hace que el DAO retorne el DTO haciendo un INNER JOIN de las dos tablas o en todo caso retornar un Map. Esto es valido o el patron no lo permite???

        1. Creo que estas confundido, el objetivo del DTO es para servir como un objeto de transferencia, como recuperes la información de la base de datos es otra historia, entonces, el DTO te permite unir la información de información de diferentes fuentes sin tener que ir al servidor en más de una ocación

  4. No sé si entendí bien . Solo sería para los GET ? En caso POST o PUT no se deberían usar .
    Vi en varios proyectos en Github que crean un DTO para actualizar y otro para crear aparte del GET. Pero eran ejemplos de CRUDs simples donde solo usaban datos para una tabla . No para dos o más como tú ejemplos que si son más útiles .

    Me gustaría saber más ,para no implementarlo mal. Agradecería tu ayuda .

    1. Hola Rasec, los DTO se pueden utilizar para cualquier operación, ya sea GET, PUT, DELETE, POST, la idea es hacer una sola llamada al servidor, ya sea en el request o en el response, y si, lo puedes utilizar para combinar información de varias tablas, de echo, es lo más normal hacerlo.

  5. Hola
    Me surgio la siguientes dudas:
    1.-Mencionas que solo se haria una peticion al servicio, pero esto podria hacerse tambien si llamas a la entiddad “Adress”.
    2.-Si necesitas obtener al usuario, lo puedes hacer tambien directamente desde la entidad Adress porque esta ya mapeada, sin necesidad de generar una especie de Entity-DTO
    3.-Ademas de la seguridad del ejemplo de la contraseña, en que afecta que una entidad se comunique con front por ejemplo JSF.

    Entiendo con esto que el uso del DTO es no dar otra funcionalidad a las Entidades que no sea el mapeo de la BD y usar entonces a los DTO para comunicar entre las diferentes capas del sistema.

    1. Hola Ivan, el problema principal de usar las Entitys es que estás atrapado en las estructura de las entidades para envíar datos, cualquier cambios de tipo de dato o formato, obliga a crear propiedades @Transient que distorsionan el uso de la Entidad, por otra parte, es común que cuando mandamos Entidades se enviemos datos de más, ya que las entidades están ligadas a otras entidades, lo que hace que por ejemplo, al mandar el Addres, termines mandando también el usuario ligado u otro dato que puede tener información sensible o que hagas más consultas de las necesarias.

      1. Me gustó esa parte de enviar datos adicionales por estar ligados. Imagino te refieres a los @Join. Gracias por aclarar mis dudas con respecto a los DTO.

  6. lo entiendo todo.
    pero tengo un problema
    tengo 3 entidades
    Alumno, matricula, pagos
    en la repositorio List findByDni(Long dni);
    me trae los datos 3 tablas
    pero yo quiero mostrar los pagos ingresando el dni del alumno.
    podrias pasar el codigo del proyecto completo para analizar dao y los servicios

  7. Impecable explicación. Y además, suelo utilizar una clase converter, que se encarga de pasar de Entidad a DTO y viceversa, para facilitar ese “traspaso” de datos. ¿Utilizás algo parecido, o simplemente creas el dto y seteas sus valores en el mismo método en el que se consultó a base de datos? Muchas gracias, saludos.

      1. Hola, y me refería a ese justamente, pero creo que no me expliqué bien. Me refiero a la forma de pasar los datos de la clase java Entidad, a la clase java DTO.

        //Create dto
        CustomerDTO dto = new CustomerDTO();
        dto.setAddress(address.getAddress());
        dto.setCountry(address.getCountry());
        dto.setZipCode(address.getZipCode());
        dto.setFullName(customer.getFirstname() + ” ” + customer.getLastname());
        dto.setId(customer.getId());

        Lo hacés siempre en el método en el que se requiere? o tenés algo así como una función con parámetros, para poder hacer esa “conversión” en cualquier parte del sistema.
        Saludos

  8. Una consulta, en este caso se usan los DTO para emitir el resultado de una api pero si fuera el caso para
    enviar un payload a una api, tambien se debería usar los DTO para usarlos como un requestBody.

    Saludos

  9. Buenas, muchas gracias por el aporte, hay una cosa que no entiendo bien, si en la aplicacion tengo una vista que permite buscar clientes aplicando filtros, por ejemplo quiero el email del cliente 1, yo tendría que hacer una sola consulta a la bd, obtener los datos y con el DTO de todos los datos de ese cliente, obtengo los que necesite o sea el email?

  10. Siéndote sincero tu artículo me ayuda bastante, siempre estuve buscando una solución al problema que planteas, de cómo no estar atado a las entidades que finalmente nos atan a las tablas de la BD si cuando uno hace un reporte o quiere llenar una grilla o cualquier cosa en capa presentación/vista puede necesitar de todo, no necesariamente de una entidad sino un poco de varias entidades relacionadas, o que al usuario se le antoje. Y lo que hago a la fecha es devolver un objeto datatable pero no me convencía, sabía que había una mejor opción y es esta, definitivamente muchas gracias. Y por favor coméntame si estoy en lo cierto.

    P.D. Preguntas bonus:
    1. Quiere decir que vamos creando las clases DTO según las necesidades del negocio la vayan pidiendo? es decir no hay una cantidad definida o algo por el estilo?
    2. Y por otra parte si lo que se necesita en presentación/vista es exactamente lo que tiene una entidad, puedo devolver directamente la entidad o sería una mala práctica? Gracias.

    1. Que bueno que te sirvio el material mi estimado Gerson, ahora bien respondiendo tus preguntas.

      1) No existe una cantidad definida, sin embargo, se suele tener minimamente un DTO por Entidad, aun que habrá siempre una que otra Entidad que no requira un DTO, debido a que no sale del backend.
      2) Definitvamente siempre es mala práctica devolver una Entidad, no hay excepciones, si la vista encaja a la perfección con la Entity, de igual forma hay que crear un DTO, se que es molesto hacer eso, pero en el futuro nos ahorrará muchos dolores de cabeza, pues permitirá que la Entidad pueda cambiar sin afectar a la vista, en otro caso, cualquier cambio en la Entidad, tendrá un impacto en la vista.

      saludos.

      1. Gracias Óscar. Compraré tu libro pronto, leí el resumen y me pareció genial. Saludos estimado y gracias por el apoyo, no hay mucha documentación práctica en español sobre arquitecturas y patrones aplicados a la vida real, tu libro y canal de youtube cubre ese vacío.

  11. Hola Oscar:
    Quiero aplicar tu patron DTO en mi aplicacion de escritorio, pero tengo unas consultas sobre como aplicarlo:
    Te comento yo uso 4 capas: Entidades, datos negocios y presentacion.
    Si quiero aplicar el patron DTO tendria que agregar una capa mas llamada DTO x ejm?
    Y donde haría la creacion del objeto DTO y asignacion de sus valores? en la capa de negocio?
    Eso quiere decir que la capa de datos me sigue devolviendo objetos de entidades, y nunca se entera de los DTO? Y es el negocio quien hace la creacion de objetos DTO y su devolucion como en tu ejemplo (CustomerService)?

    Te agradezco me ayudes.

    1. Hola Manu, no el DTO no es una capa, mas bien es como el puente entre la capa de servicios y la presentación, de esta forma, la capa de datos solo trabaja con entidades y la de servicios podría regresar los DTO a la vista, de esta forma, la vista solo trabajar con DTO.
      saludos.

  12. Usar DTOS van a hacer que dupliques cada uno de tus objectos de dominio como mínimo dos veces.

    Para tomar la decisión, balancéa el coste y el beneficio de ese aumento de carga de trabajo en tu proyecto y cómo va a impactar eso en los resultados del proyecto.

    En proyectos de corta vida, donde hay un grupo de pequeño programadores que pueden trabajar en distintas áreas de código sin colisionar puedes perfectamente evitar el uso de DTOs

    https://stackoverflow.com/questions/1440952/why-are-data-transfer-objects-dtos-an-anti-pattern

    Cuando uses la palabra “inexpertos” con otros profesionales que toman decisiones distintas a las que tú tomarías justifícalo muy bien. Payaso.

    1. En mi experiencia, decir que es que no hay tiempo, que somos pocos programadores, que el sistema casi no va a cambiar, es la excusa perfecta para aplicar todas las malas prácticas posibles. En mi lugar, yo siempre aplico buenas prácticas SIEMPRE, incluso si soy la única persona en el mundo que le va a mover a ese código, ya que aplicar siempre las buenas prácticas se hacer un hábito, lo cual con el tiempo ya no representa una carga mayor de trabajo, sino que se hace de forma automática e instintiva.
      Si lo que buscas es cualquier justificación para no aplicar buenas prácticas, pues puedes encontrar muchas referencias en internet, al final el estoy seguro que el programa funcionará, incluso más rápido, porque no hace falta convertir Entitys a DTO, pero a costa de su calidad, allí te lo dejo para reflexionar.

  13. Hola muy buena explicacion, veo por ahi en los comentarioas algunas confusiones por la parte de varias llamadas para traer informacion, quisiera aportar que es correcto lo que mencionas y que tambien las DTO son flexibles, las puedes conformar con diferentes campos que se requieran en tu servicio, por ejemplo tenemos dos entidades, una llamada Area y SubArea, al traer informacion de las SubAreas, quizas el que consuma o te pida el servicio te diga, sabes que no solo quiero la SubArea, tambien quiero saber el nombre del area a la que pertenece, ahi entra la flexibilidad de la DTO puedes conformarla con (idSubArea, nombreSubArea, idArea, nombreArea) cosas que con las entidades no es recomendable hacer.

    Las DTO es lo mejor para el intercambio de datos, por la flexibilidad que nos da y seguimos un patron de diseño y si eso lo llevamos a la Programacion Orientada a Aspecto es aun mucho mejor.

    Excelente explicacion.

    Saludos.

  14. Que buena explicación! Graciasss Me ha servido incluso para entender lo de serializable. Una consulta, en caso quiera recibir datos (petición http post o put) a los DTO es recomendable agregarles validaciones? o basta con ponérselas a las entidades?

    1. Las entidades y los DTO se validan por separado, ya que la Entidad se valida en función de las reglas de persistencia, es decir, los constrains de la DB, mientras que los DTO se validan en función de los datos de entrada, que es opcional, que no, que valores se permiten, etc.

      saludos.

    1. Hola tengo una pregunta.

      En ocasiones se habla de DTO, Model y Entity.
      Entiendo que:
      DTO: Es para enviar y recibir datos.
      Model: Para transportar datos entre capas.
      Entity: Para la comunicación con la base de datos, mediante el ORM.

      Es esto válido? Porque solo se habla de DTO y Model?

      1. Los 3 son terminis diferentes, DTO como lo mencionas, es para enviar y recibir datos, pero tambien se entre capas. Model viene del patrón MVC, donde el mode representa la información que tiene la página, y Entity es como bien mencionas, para mapear clases a entidades persistentes.

  15. La explicacion es buenisima, es facil de enteder. Acabo de leer tambien el de Java Converter Patterns y esta muy bueno tambien.
    Te hago una consulta, si yo hago una consulta que devuelve un “page”, por ejemplo:
    public Page findByUsuario(Usuario usuario, Pageable pageable);
    y quiero devolver un DTO, deberia convertir el Page en DTO con toda la estructura de page? o como lo resolverias?

    1. Si, deberías de convertiri el Page a un DTO, pero no es necesario que retornes todos los cambios, ni con el mismo nombre ni con el mismo tipo de dato, el DTO permite personalizar la forma con la que transmitimos la información, por ejemplo, si tu objeto tiene un campo de tipo Date o Calendar, seguramente querás retornar un String en formato dd-mm-yyyy, en lugar del objeto Calendar, para eso te sirve el DTO.

  16. He visto muchos videos que no explican tan bien como tu lo haces en este articulo, muchos estan desorganizados, con falta de información y que se nota que no saben bien del tema.
    Muchas gracias por hacer algo de tanta calidad <3

  17. Hola, muy pero muy clara tu explicación. Sólo dos preguntas:
    1. Una clase DTO siempre debe implementar Serializable?
    2. Si es así, por que?
    Muchas gracias

    1. No es necesario, al menos que envies los objetos mediante invocación remota o los serialices mediante Sockets, en el caso de REST una clase se convierte en JSON, por lo tanto la serialziación no es necesaria

  18. Hola Oscar, muchas gracias por el artículo, muy bien explicado y de manera que se entiende fácilmente.

    No conozco mucho sobre Entity y como hacer la conexión a la base de datos, por lo que buscaré algún artículo en Internet que me ayude con este tema; o en su caso, ¿Tendrás algún artículo, curso, o libro que me recomiendes?, he visto que tienes varios cursos y libros muy interesantes.

    Tengo el siguiente tema:

    1.- Desplegué en WildFly el Driver .jar para conexión a la BD PostgreSQL, donde tengo una BD de prueba,
    2.- Configure un Datasource en WildFly utilizando el despliegue del Driver.

    Mi idea (y no sé si sea errónea y así no sea cómo funciona, ya que no tengo mucho conocimiento del tema), es utilizar ese Datasource en una WebApp. ¿Sabes si es posible hacer esto?

    Saludos.

    1. Mira, de entrar te recomiendo dos cursos muy buenos que estan orientados al desarrollo de API y persistencia, que es el curso de Mastering API REST y el de Mastering JPA.
      Por otro lado, tambien doy consultoría para empresas, si es algo que requieres donde trabajas lo podemos platicar, mi correo es oscarblancarte3@gmail.com

  19. Buen contenido, gracias.
    Mi pregunta es… Si tengo en mi modelo de BD una tabla Personas con un campo idRol que la relaciona a una tabla roles (profesor o alumno), también tengo una tabla Materias y una tabla intermedia para evitar el M:M llamada Materias_Profesor (con su id , el id de Persona y id de Materias). La forma correcta de yo poder registrar y recuperar esas Personas que son de Rol Profesor sería a través de un DTO? Espero puedas ayudarme a aclarar o corregir mi idea, gracias.

  20. Hola Oscar acabo de comprar tu libro Arquitectura de Software, podrías explicarme qué tipo de patrón es un DTO. En este articulo mencionas que DTO es un patrón de diseño, sin embargo, en el libro aparece como un patrón arquitectónico. Muchas gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *