No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso de Java Spring

Curso de Java Spring

Alejandro Ramírez

Alejandro Ramírez

¿Qué es el patrón Data Mapper y qué resuelve?

19/35
Recursos

Aportes 38

Preguntas 21

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Otra forma de instalar plugins en IntelliJ es ir a files > Settings o Ctrl + Alt + S / en Mac es con command + , (coma)
En el panel izquierdo se selecciona "plugins"
y solo queda buscar “MapStruct Support” e instalarlo 😃

Si alguno esta viendo esto en 2022
Los pasos de instalación de MapStruct Plugin son:

  1. Abrir opción “Preferencias”
  2. Clic en la opción “Plugins”
  3. Clic en el engranaje
  4. Clic en “Instalar desde disco”
  5. Buscan el ZIp
  6. Clic en OK
  7. Reiniciar el IntelliJ IDEA

Y listo 😃 espero les sirva

DATA MAPPER

  • Convertir o traducir dos objetos que pueden hacer una misma labor

  • No exponer directamente la base datos medianta la API

  • Esto garantiza que ningun agente externo, vizualice la forma del diseño de la base de datos

  • Desacoplar la API de una base de datos puntual

  • En el caso que se desee integrar una nueva base de datos con otros campos, pero que sea para el mismo proyecto, no es necesario cambiar todo el código, simplemente se crea otro traductor que sirva para traducir la nueva tabla al dominio

  • Evita tener campos innecesarios en la API

  • Evitar mezclar idiomas en el dominio

también puedes instalar el plugin desde el IDE con clic en File > Settings (Ctrl + Alt + S) seleccionar la opción Plugins y buscar MapStruct Support e instalar 😋

“Estamos acoplando nuestra aplicación a la capa de la persistencia y nuestro proyecto está construido bajo un enfoque de dominio” Palabras del profe
¿Alguien me apoya explicando un poco mas lo que significa?

Porfa

Profe me puedes dar una explicacion breve del Optional que no lo tengo muy claro aún?

Cordial saludo profe, Avanzamos en el curso pero todavia no ejecutamos el proyecto teniendo en cuenta que envarias partes del codigo no es raro que nos de error a nosotros que estamos aprendiendo pensaria que seria bueno tambien probar el codigo.

Muy buenas, en caso de manejar el dominio y los entities en inglés, tendriamos dos clases con el mismo nombre que puede ser un poco molesto. Que recomiendan hacer en ese caso? Tal vez le podemos poner en un sufijo Entity.

hay algunas cosas a tener en cuenta, no es muy deseable tener variables con el mismo nombre de la clase, adicionalmente es redundante tener en las variables composiciones con el nombre de la clase por ejemplo

public class Category {

private int categoryId; // deberia de llamarse id, ya se sobre entiende que este //campo hace referencia al id de la categoria
private String category; //deberia llamarse name o description
private boolean active;

¿Que ofrece el patrón Data Mapper?

No expone la DB a la API
Desacopla la API de la DB
Facilita mudar a otro moto de DB
Evita tener campos innecesarios en la API

Estoy usando Spring Tool Suite y también esta el plugin en el market, lo pueden buscar como Mapstruct Support 😁👍

Ahora entiendo todo, yo la verdad no le veía sentido al mapper, pero con esta explicación ya me hace sentido.

Si utilizamos los nombres en inglés, entonces no es necesario implementar lo del mapper?

DataMappers - Mapeando los datos

Nos permite desacoplar la persistencia de la aplicación. Consiste en convertir o traducir varios objetos que pueden cumplir la misma labor. De esta forma podemos:

  • Independizar la base de datos de la API, desacoplanto la capa de persistencia o de negocio.
  • Desacoplarnos de una base de datos puntua, así no tendríamos que refactorizar todo el código si la capa de persistencia cambia.
  • Evitar campos innecesarios en la API.
  • Evitar mezclar idiomas en la aplicación.

Me gustó cómo explicó el concepto de Data Mapper.

Se crean los DTO y no se usan los entity en la capa de dominio debido a la implementación del patron Data Mapper.

Beneficios del Data Mapper:

  1. Al separarse los objetos del dominio de los de la persistencia, si se cambia la bd o la table, solo hay que
    hacer cambios en el lado de la persistencia, dejando el dominio intacto y no modificando la lógica de negocio.

  2. Es más seguro porque podemos mantener en los entities los nombres de cada columna de la base de datos,
    evitando usar la annotation @Column(name = “”). Podemos usar en las clases Entity propiedades en español
    (si es que los nombres de los campos de la bd están en español) ya que en la parte de la lógica que es lo que va
    a ver principalmente un desarrollador va a estar en inglés.

Este curso está genial! Y si te apoyas en chatGPT para profundizar más y aclarar dudas, el aprendizaje se vuelve más significativo todavía.

Estaba navegando y encontré esta imagen, logré entender cuál es la funcionalidad del patrón Data Mapper

Sé que el giro para hablar con mapeadores y todo eso pudo dejar a varios confundidos como a mí, les comparo un video donde pueden extender más sus conocimientos del tema.

https://www.youtube.com/watch?v=4p6z6hL8BNg

otro punto a tener en cuenta es que en la clase product se tiene el campo categoryId y tambien se tiene el campo Category (que tiene intiernamente el campo id), esto a mi parecer es redundante, si voy a mostrar mi categoria completa en los productos no hay necesidad de crear un campo para categoryId

¿Que ofrece el patrón Data Mapper?

  • No expone la DB a la API
  • Desacopla la API de la DB
  • Facilita mudar a otro moto de DB
  • Evita tener campos innecesarios en la API

minuto 2 y ya estoy enamorándome de Data Mapper!!!

  1. File
  2. Settings
  3. Plugins

Gradle

dependencies {
    ...
    implementation 'org.mapstruct:mapstruct:1.5.3.Final'
 
    annotationProcessor 'org.mapstruct:mapstruct-processor:1.5.3.Final'
}

Maven

...
<properties>
    <org.mapstruct.version>1.5.3.Final</org.mapstruct.version>
</properties>
...
<dependencies>
    <dependency>
        <groupId>org.mapstruct</groupId>
        <artifactId>mapstruct</artifactId>
        <version>${org.mapstruct.version}</version>
    </dependency>
</dependencies>
...
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.1</version>
            <configuration>
                <source>1.8</source> <!-- depending on your project -->
                <target>1.8</target> <!-- depending on your project -->
                <annotationProcessorPaths>
                    <path>
                        <groupId>org.mapstruct</groupId>
                        <artifactId>mapstruct-processor</artifactId>
                        <version>${org.mapstruct.version}</version>
                    </path>
                    <!-- other annotation processors -->
                </annotationProcessorPaths>
            </configuration>
        </plugin>
    </plugins>
</build>

Wow, todo lo que se hace actualmente es fascinante

Punto importante para saber para que sirve ProductRepository

Todo muy claro para mí. Muy bien explicado.

Por que en la Entidad es recomendable usar clases para lso tipos de las propiedades como Integer para el id, y en dominio si se pueden usar tipos primitivos hay alguna razón en especial?.

Tengo la duda de sobre si la api la empezamos a construir con los nombres en inglés, el data mapper es necesario? no me quedó muy claro esto :(
Tengo una pregunta. Por qué no se están utilizando DTOs como destino de los mapeos provenientes de los Entities? Entiendo que este es el objetivo de este recurso, inclusive se creo el paquete "dto" pero se ignoraron para realizar esta tarea de mapeo.

Videos atras alguien venia del futuro y no le hice caso, ya entendi.

domain es un posiblle espejo de los posibles entity

ufff, super este tema de seguridad

Esto seria igual a realizar con DTOS ? o el DTO cambia en algo?

baia baia