Implementación de Servicios de Dominio en Java con Spring Framework
Contenido del curso
Kevin Daniel Guzmán Delgadillo
David Barrera
Wilmar Malaver Malaver
Manuel Eguiluz
Johson Rodriguez Rodenas
Cristian Felipe Patiño Cáceres
Luis Enrique Carreño Herreño
Alejandro Ramírez
Profesor
Yuliani Galindo
Yeferson Yuberley Guerrero Castro
Cristian David Restrepo Marin
Jorge Ramírez Santiago
Brayan Olarte
Alberto Carlos Castro Castro
Rolando Mamani Salas
Edward Alejandro Garcia Gonzalez
Gaiserick Jhonatan Ortiz Ramírez
Alejandro Ramírez
Profesor
Sebastian Domingo Villar Segura
Álvaro Fabian M
Alejandro Ramírez
Profesor
Cesar Dominguez
Alejandro Ramírez
Profesor
Christian López
Alejandro Ramírez
ProfesorChristian López
Alejandro Ramírez
Profesor
LEONARD CUENCA
Deymer Hernández
Juan Diego Garzón Ovalle
Pablo Andrés Prado Diaz
John Soto
Daniel Felipe
John Soto
Jhonny Vargas
Matias Preiti
David Barrera
LEONARD CUENCA
Estaba un poco confundido con el concepto de Repositorio y Servicio. Así que me puse a indagar un poco y resulta que el repositorio es la capa simple de acceso o de comunicación con el sistema de almacén de datos (ojo, solo comunicación), mientras que el servicio es la lógica de acceso a estos datos desde la aplicación, así pues un ejemplo sería: Entras a un cajero automática y sacas dinero de tu cuenta, el banco es el repositorio, y el cajero es el servicio.
Que gran explicación, gracias hombre!
Muchas gracias por la explicación, excelente
Las implementaciones del método delete son buenos ejemplos de los estilos declarativo e imperativo. El primero define el qué va a hacer el código mientras que el segundo define el cómo y por consiguiente se ven más detalles. Cabe aclarar que el estilo declarativo no puede existir sin el estilo imperativo ya que el primero se apoya en el segundo para ocultar las estructuras de control (if, else, switch, etc).
No entendi :( , como explicarlo en palabras mas simples.
Hola Johson, a lo que Manuel se refiere es: Un código declarativo no le importa como se hará la operación solo le importa que operación es la que va a realizar:
@Override public void delete(int productId) { productoCrudRepository.deleteById(productId); }
El método delete de la clase ProductoRepository es un ejemplo, en este caso solo nos interesa el que y no el como. Asi que no se ven los detalles y se basa en otras clases que internamente harán ese proceso.
Por otro lado un estilo imperativo se preocupa del como se va a realizar la operación:
public boolean delete(int productId) { return getProduct(productId) .map(product -> { productRepository.deleteProduct(productId); return true; }).orElse(false); }
El método delete de la clase ProductService es un ejemplo, en este caso si nos interesa ver un poco mas a detalle como realizar la eliminación y en este caso primero se revisa si el producto realmente existe y también nos preocupa devolver una bandera que le indique al controlador si fue posible o no realizar dicha eliminación.
Otro ejemplo es cuando usas alguna librería, donde te preocupa hacer una operación pero no tanto como se hará ya que la librería se va a encargar de esto. En este caso tu código será de forma declarativa mientras la librería será imperativa.
¿Porqué es necesario verificar que el producto exista en la base de datos antes de borrarlo? El Id normalmente se obtiene de procesos anteriores como de un listado, y si queremos saber si el borrado es exitoso se podría obtener el número de fila(s) eliminada(s) ... lo digo porque esto se ve muy bonito y mantenible, pero es costoso en máquina... ¿no?
Tienes toda la razón, Luis. Lo hice así era pensando en implementar una solución más imperativa que me permita describir claramente cuando se realiza bien o no este procedimiento.
Una solución mucho más optima sería controlar esto con un try-catch, así:
public boolean delete(int productId) { try { productRepository.delete(productId); return true; } catch (EmptyResultDataAccessException e) { return false; } }
Gracias por mejorar el curso! 🚀
A mi "EmptyResultDataAccessException e" me lo marca como error
@Service:
Intermediario entre el controlador de la API y el repositorio
👍
Creo que todo tiene un porque, al principio lo veía como algo repetitivo pero ahora tengo mas claro el porque se programa así. Gracias profesor, excelente curso.
X2
Nuestros servicios son negociadores entre el repositorio y los controladores
Muy buen resumen
Para el que quiera entender de donde vienen estos objetos que nombra el profesor como el Optional o el método .map() ... esto hace parte de lo que es Programación Funcional (Un paradigma de programación) de la cual Java año tras año ha tratado de adaptarse a este. Actualmente se encuentra un curso de Java Funcional en platzi y es excelente. https://platzi.com/cursos/java-funcional/
Creo que de esta forma es más legible el método delete:
public boolean delete(long id) { if (get(id).isEmpty()) { return false; } repository.delete(id); return true; }
Cuando hablamos de legibilidad todo es cuestión de gusto y costumbre. Al final del día lo más importante es escribir código que nosotros mismos entendamos, que pasado un tiempo y al volver a verlo no digamos "WTF, ¿qué cosa hice aquí? 😵".
Esta linea se puede leer de la siguiente forma?, no entendí muy bien la instrucción Si existia el producto y fue eliminado responde true de lo contrario response false return getProduct(productId).map(Product ->{ productoRepository.delete(producttId); return true; }).orElse(false);
Más o menos, aunque veo que entendiste muy bien la idea del map y el orElse. Como el delete del ProductRepository no retorna nada entonces no puede ser una condición incluyente a como lees la instrucción. Sería: "Sí existe el producto entonces elimínalo y retorna true; de lo contrario retorna false".
Es buena practica, agregar en nuestra clase Service las validaciones del negocio?
Las validaciones del negocio deberían ir en el servicio o en la clase del objeto de dominio.
Como se maneja la atomicidad de una transaccion que realiza multiples operaciones en la base de datos?
Para manejar la atomicidad se usa la anotación @Transactional. Te recomiendo el artículo Managing Transactions with Spring and Spring Data JPA para aprendas más de esta anotación y transacciones ACID.
es obligatorio crear un servicio por cada entidad de repository? o un servicio puede funcionar como patron Facade y exponer todos los servicios de un módulo por ejemplo?
No es obligatorio pero si es una buena practica. El principio Single responsibility de los SOLID nos sugiere de que los componentes de nuestro sistema deberían estar diseñados de tal forma de que su responsabilidad sea única y solo se encarguen de algo especifico dentro de nuestro dominio. Esto para buscarcomo siempre, bajo acoplamiento / alta cohesión.
Significado de @Service
El delete manejando la exception
public boolean delete(int productId) {
Optional<Product> productOpt = getProduct(productId);
if (productOpt.isEmpty()) {
return false;
}
try {
productRepository.delete(productId);
return true;
} catch (Exception e) {
return false;
}
}
Si quiero colocar una Api externa, entonces la lógica la haría en ProductRepository de la persistencia?
La respuesta correcta a esta pregunta depende de varias consideraciones y dependiendo la evaluación de las mismas será la desición correcta:
En fin, es responsabilidad del programador, el arquitecto de la solución y el dinero sobre la miesa lo que dicata que camino tomar de acuerdo a la aplicación, la proyección a futuro de esta (va a crecer o es casi estatica), tiempos de entrega, recursos y compromisos con el sistema.
Hola a todos, he revisado paso a paso todas las clases hasta aquí y en el código descargado o en el que yo mismo hice, me sale este error al ejecutar:
*************************** APPLICATION FAILED TO START *************************** Description: Field mapper in com.platzi.market.persistence.ProductoRepository required a bean of type 'com.platzi.market.persistence.mapper.ProductMapper' that could not be found. The injection point has the following annotations: - @org.springframework.beans.factory.annotation.Autowired(required=true) Action: Consider defining a bean of type 'com.platzi.market.persistence.mapper.ProductMapper' in your configuration.``` No le he podido dar con el chiste. Gracias, Salu2.
mira lo que dice el error, dice que esta buscando un bean de tipo ProductMapper en la clase ProductoRepository y no lo encontró. Lo que puede estar pasando es que la clase ProductMapper no ha sido definida como un component de spring. Intenta anotar el mapper con @Component
Hola @feldan9119, gracias por el comentario!, Esta es la definición de la clase ProducMapper
package com.olsoftware.platzimarket.persistence.mapper; import java.util.List; import org.mapstruct.InheritInverseConfiguration; import org.mapstruct.Mapper; import org.mapstruct.Mapping; import org.mapstruct.Mappings; import org.springframework.stereotype.Component; import com.olsoftware.platzimarket.domain.Product; import com.olsoftware.platzimarket.persistence.entity.Producto; @Component @Mapper(componentModel = "spring", uses = {CategoryMapper.class}) public interface ProductMapper { @Mappings({ @Mapping(source = "idProducto", target = "productId"), @Mapping(source = "nombre", target = "name"), @Mapping(source = "idCategoria", target = "CategoryId"), @Mapping(source = "precioVenta", target = "price"), @Mapping(source = "cantidadStock", target = "stock"), @Mapping(source = "estado", target = "active"), @Mapping(source = "categoria", target = "category") }) Product toProduct(Producto producto); List<Product> toProducts(List<Producto> productos); @InheritInverseConfiguration @Mappings({ @Mapping(target = "codigoBarras", ignore = true) }) Producto toProducto(Product product); }
Según lo que entendí es que @Mapper es de Struct y para que quede enlazado como componente de Spring se usa el atributo componetModel, por lo que no hace falta colocar el @Component, sin embargo hice el ajuste, pero me dio la misma excepción.
Incluso me baje las fuentes de la clase #34 y me sale la excepción.
Gracias,
Salu2.
No hace falta usar el @Autowired en este caso porque Spring buscará la instancia de ProductRepository en su contenedor y se dará cuenta que existe creado previamente uno con el nombre productRepository, mismo nombre que el del atributo en ProductService. No obstante es buena práctica anotarlo con @Autowired
Otra opcion para el Delete, es con una lamda, queda mas prolijo me parece.
public boolean delete(int productId){ return getProduct(productId).map(product -> true).orElse(false); }```
Creo que no estarías borrando nada, solo devolviendo true y false en caso de que exista o no
Como usar el orElse del metodo map
