¿Cómo gestionar la agregación de órdenes en NestJS?
En el desarrollo de aplicaciones con NestJS, la gestión de órdenes de compra puede simplificarse creando un servicio y un controlador dedicados. Este proceso se inicia utilizando el Nest CLI para generar los componentes necesarios. Vamos a explorar cómo se hace.
¿Cómo generamos el servicio y el controlador?
Para iniciar, en la terminal empleamos el comando nest generate, especificando que queremos un servicio (s) y un controlador. La estructura se ubicará bajo el módulo de usuarios, dado su contexto en la aplicación:
nest generate service users/service/ordered --flat
nest generate controller users/controllers/ordered --flat
Con estos pasos se crean los archivos básicos y se agregan al UserModule sin necesidad de ningún ajusto adicional.
¿Qué es un DTO y cómo se crea?
El DTO (Data Transfer Object) delimita los datos que serán transferidos al momento de crear una orden. Creamos una clase CreateOrderDTO:
Este DTO identifica al cliente relacionado, validando que la información sea positiva y no vacía, integrándose con la documentación Swagger.
¿Cómo desarrollamos las funciones CRUD?
En el OrderedService, implementamos las funciones básicas CRUD: "crear", "actualizar" y "eliminar", apoyándonos en dos repositorios: OrderRepo y CustomerRepo. Utilizamos InjectRepository:
Para crear una orden, solo es necesario el CustomerID, y la instancia de la orden se guarda en el repositorio correspondiente.
Incorporación de ítems en la orden
Una vez establecida la orden de compra, el siguiente paso es gestionar la inclusión de productos, tratados como ítems en una entidad ternaria. Esta sección detalla cómo se procede.
¿Cómo creamos el DTO para los ítems?
Para gestionar los ítems, creamos un DTO OrderItemDTO que detalla los elementos necesarios:
Finalmente, revisamos la gestión mediante herramientas como Insomnia y pgAdmin para verificar la correcta inserción de datos y resolver inconvenientes de inyección de dependencias mediante la exportación correcta de módulos. Validamos las relaciones complejas en entidades y garantizamos que los endpoints expongan toda la información necesaria.
Este enfoque facilita el manejar relaciones muchos a muchos en bases de datos utilizando una estructura de módulos bien definida, inyecciones de dependencias y validaciones de DTO que protegen y estructuran la integridad de nuestros datos, ofreciendo una manera eficiente de administrar las operaciones de la aplicación.
nest g s users/services/orders --flat
nest g co users/controllers/orders --flat
nest g co users/services/order-item --flat
nest g co users/controllers/order-item --flat
Cuando usan el comando generate del CLI pueden pasarle el argumento --no-spec para que no cree los archivos para pruebas unitarias
Esta super bien la clase, pero como sujerencia estas deben ser mas cortas. Lo ideal es que duren un maximo de 10 minutos porque de lo contrario es mayor el esfuerzo mental que un alumno debe hacer y facilmente pierda el hilo del tema.
Por favor el Cursos de Pruebas unitarias , seria Genial Gracias NicoBite
Ya pasaron años, pero por favor un curso de testing con NestJS
Otro tip, pueden usar nest generate resource <nombre-del-recurso> para autogenerar un CRUD (link):
$ nest g resource users
>?What transport layer do you use?GraphQL(code first)>?Would you like to generate CRUD entry points?Yes>CREATE src/users/users.module.ts(224 bytes)>CREATE src/users/users.resolver.spec.ts(525 bytes)>CREATE src/users/users.resolver.ts(1109 bytes)>CREATE src/users/users.service.spec.ts(453 bytes)>CREATE src/users/users.service.ts(625 bytes)>CREATE src/users/dto/create-user.input.ts(195 bytes)>CREATE src/users/dto/update-user.input.ts(281 bytes)>CREATE src/users/entities/user.entity.ts(187 bytes)>UPDATE src/app.module.ts(312 bytes)
en este gurso si seria con API REST y no graphQL
No es mejor practica traer el servicio de customers y productos al servicio de ordenes, en lugar de injectar el repositorio( de productos y customers) en el servicio de ordenes?
Eso depende, si se usa una sola función del servicio de customers o se va a hacer algo diferente a lo que hay en el servicio de customers entonces no hay necesidas, pero si vas a usar varios de los métodos de ese servicio entonces sí es mejor traer el servicio que usar el repositorio.
Profe: Al momento de crear una nuevo item de una orden, ya estoy validando que efectivamente tanto la orden como el producto existan en la base de datos, lo que no he podido validar es que si ya existe un item con esa misma orden y ese mismo producto asociado no lo ingrese a la base de datos:
Acà mi còdigo:
async create(data: CreateOrderItemDto){
const order = await this.orderRepo.findOne(data.orderId);
const product = await this.productRepo.findOne(data.productId);
console.log(order);
console.log(product);
if(product !== undefined && order !== undefined){
const item = new OrderItem();
item.order = order;
item.product = product;
item.quantity = data.quantity;
return this.itemRepo.save(item);
}else{
if(product === undefined && order === undefined){
console.log("Orden y producto no existen");
}else if(order === undefined){
console.log("Orden no existe");
}else if(product === undefined){
console.log("Producto no existe");
}
}
}
Alguien se le ocurre como solucionarlo?
Puedes utilizar el decorator @Unique en el entity, a continuación te dejo un ejemplo:
Te dejo un enlace a la documentación: Decorator Reference | TypeORM @Unique
a este punto del curso tengo una duda, por que esta combinando dentro de users lo que seria customers y ordenes no se supondria que como buena practica serian cada uno un modulo por separado y no estar todo dentro del modulo users?