ProductHttpService
Clase 19 de 25 • Curso de TypeScript: Programación Orientada a Objetos y Asincronismo
Contenido del curso
Gerardo Alberto Soto Alvarez del Castillo
student•
hace 3 años
Ronaldo Delgado
student•
hace 2 años
Clase 19 de 25 • Curso de TypeScript: Programación Orientada a Objetos y Asincronismo
Contenido del curso
Gerardo Alberto Soto Alvarez del Castillo
Ronaldo Delgado
Víctor Andrés Córdova Poma
Jaime Eduardo Falla Cardozo
Carlos Rodríguez
Sergio Sanchez
Carlos Rodríguez
Paolo Joaquin Pinto Perez
Gaspar.meza
Brahyan Antonio Martinez Madera
Diego Ivan Nacimiento
Nery Alberto Cano Ortigoza
Royer Guerrero Pinilla
Luis Gomero
Jorge Arias Argüelles
Ronaldo Delgado
Andrés Felipe Eslava Zuluaga
En una arquitectura de software, los DTOs (Data Transfer Objects) son objetos utilizados para transferir datos entre diferentes componentes del sistema, como capas, servicios o módulos. Su propósito principal es encapsular y transportar datos sin incluir lógica o comportamiento adicional.
Los DTOs se utilizan para representar la estructura de datos necesaria para una operación o interacción específica. Pueden contener propiedades que representan los datos relevantes para una operación, como los campos de una entidad, y pueden adaptarse según las necesidades de la comunicación.
Algunas ventajas de utilizar DTOs son:
Separación de responsabilidades: Los DTOs permiten separar los datos del modelo de dominio y los datos utilizados en la comunicación entre diferentes componentes. Esto evita la propagación de estructuras de datos específicas del dominio en todo el sistema.
Flexibilidad y escalabilidad: Los DTOs permiten agregar o modificar los datos transferidos sin afectar directamente las entidades del dominio o los modelos internos. Esto facilita la evolución y escalabilidad del sistema.
Optimización de la comunicación: Al utilizar DTOs, se pueden optimizar las transferencias de datos al enviar solo la información necesaria en lugar de transferir todo el estado de una entidad o modelo.
genial
Opino que debería se debería usar patch en vez de put en la función update, ya que no se está actualizando todo un producto por default, si no de manera parcial.
Lo hace, porque el endpoint está definido como put https://api.escuelajs.co/docs/
En los métodos put, post, delete, patch no tiene sentido usar { data }, usar { status } sí!
Por curiosidad, por que?
Porque en estos métodos put, post, delete, patch, sólo enviaremos datos o alguna instrucción, en el método get si es como una consulta y necesitaremos el data!
Para implementar lo que nos pide ProoductService se puede generar con este shortcut(que es lo que creo utilizo el profesor): *Primero posicionan el cursor sobre ProductHttpService y luego...
En Mac: [Cmd + . (punto)] En Windows: [Ctrl + .(punto)]
Les aparecera el menu y le dan a implement interface
Esta muy pequeña tu imagen, no se ve nada
Solo tienes que darle click derecho y abrir imagen en otra pestaña
También se podría utilizar una clase abstracta en lugar de una interfaz
productsAbstract.service.ts:
import { Products } from "../models/product.model"; import { CreateProductDto, UpdateProductDto } from "../dtos/products.dto"; export abstract class ProductServiceBase { abstract getAll(): Products[] | Promise<Products[]> abstract create(data: CreateProductDto): Products | Promise<Products> abstract update(id: Products["id"], changes: UpdateProductDto): Products | Promise<Products> abstract findOne(id: Products["id"]): Products | undefined | Promise<Products | undefined> }
productsMemory.service.ts:
import { faker } from '@faker-js/faker'; import { Products } from '../models/product.model'; import { CreateProductDto, UpdateProductDto } from '../dtos/products.dto'; import { ProductServiceBase } from './productsAbstract.service'; export class ProductsService extends ProductServiceBase { private products: Products[] = []; getAll (): Products[] { return this.products; } create (data: CreateProductDto): Products { const newProduct = { ...data, id: faker.datatype.number(), creationAt: faker.date.recent(), updatedAt: faker.date.recent(), category: { id: data.categoryId, name: faker.commerce.department(), creationAt: faker.date.recent(), updatedAt: faker.date.recent(), image: faker.image.imageUrl(), } } return this.add(newProduct); } private add (product: Products): Products { this.products.push(product); return product; } update (id: Products['id'], changes: UpdateProductDto): Products { const index = this.products.findIndex(item => item.id === id); if (index === -1) throw new Error("El producto no existe."); const prevData = this.products[index]; this.products[index] = { ...prevData, ...changes } return this.products[index]; } findOne (id: Products["id"]): Products | undefined { return this.products.find(item => item.id === id); } }
productosHttp.service.ts:
import axios from "axios"; import { Products } from "../models/product.model"; import { CreateProductDto, UpdateProductDto } from "../dtos/products.dto"; import { ProductServiceBase } from "./productsAbstract.service"; export class ProductsService extends ProductServiceBase { private url = "https://api.escuelajs.co/api/v1/products"; async getAll() { const { data } = await axios.get<Products[]>(this.url); return data; } async create(data: CreateProductDto) { const newProduct = await axios.post<Products>(this.url, data); return newProduct.data; } async update(id: Products["id"], changes: UpdateProductDto) { const { data } = await axios.put<Products>(`${this.url}/${id}`, changes); return data; } async findOne(id: Products["id"]) { const { data } = await axios.get<Products>(`${this.url}/${id}`); return data; } }
como conectariamos el ProductMemoryService a Redux por ejemplo? o este panera de manejar los datos podria ser mejor o mas eficiente?
Los servicios no tendria mas sentido llamarlos repository. Es decir tener ProductHTTPRepository y ProductMemoryRepository en lugar de service?
creo que la convencion en ts es usar *.service.ts. Quizas en otros lenguajes como Java es mas comun usar una capa de repository que se conecta a la BD y una capa de service que se encarga de la logica de negocio.
Para tipar el retorno de un método en TypeScript de modo que retorne un Product como promesa o valor directo, puedes usar una firma de método con una unión de tipos. Aquí tienes un ejemplo:
class ProductService { getProduct(): Promise<Product> | Product { // lógica para retornar un producto } }
En este ejemplo, el método getProduct puede devolver un Product directamente o una Promise<Product>, permitiendo flexibilidad en la forma en que se maneja la asincronía. Asegúrate de manejar ambas posibilidades al usar el método.
me gusto esta clase
La forma en que lo implemento es la siguiente:
import axios from "axios"; import { CreateProductDto, UpdateProductDto } from "../dtos/product.dto"; import { ProductService } from "../models/product-service.model"; import { Product } from "../models/product.model"; export class ProductHttpService implements ProductService { private URL = "https://api.escuelajs.co/api/v1/products"; async getAll() { const { data } = await axios.get<Product[]>(this.URL); return data; } async create(dto: CreateProductDto) { const { data } = await axios.post(`${URL}/${dto}`); return data; } async update(id: Product['id'], changes: UpdateProductDto) { const { data } = await axios.put(`${URL}/${id}`, changes); return data; } async findOne(id: Product['id']) { const { data } = await axios.get(`${URL}/${id}`); return data; } async add(product: Product) { const { data } = await axios.post(`${URL}/${product}`); return data; } async delete(id: Product['id']) { const { data } = await axios.delete(`${URL}/${id}`); return data; } }
. Recibo comentarios si algo no funciona. Este profesor es la ley!