search

gasparoberti / ApiRest

API REST utilizando .NET 5. Arquitectura en capas y utilización del patrón Repository. EntityFramework para la persistencia y JWT con Identity para la seguridad de nuestra API.
0 stars 0 forks source link

2-persistencia #3

Closed gasparoberti closed 2 years ago

gasparoberti commented 2 years ago

En este branch se va a mejorar la arquitectura y a partir del patrón repository y una colección de memoria se va a asegurar persistencia para probar la api.

gasparoberti commented 2 years ago

En la capa de acceso a datos para que el repositorio se pueda conectar agregamos lo que nos permite adaptar nuestro proveedor de datos (EF, algo en memoria, ADO.NET, etc) que es el conexto de base de datos. Este contexto es genérico e implementa una interfaz que se configura en la capa de abstracciones (IDbContext) que a su vez implementa la interfaz de crud.

En principio guardaremos datos en una lista para poder hacer las pruebas en memoria con el contexto. Mas adelante lo haremos con una BD. Estos objetos están en un repositorio (un contenedor) y este contenedor se instancia depende como definamos la inyección de dependencia por lo que esto se va a eliminar constantemente.

Se crea también un objeto genérico que permite transformar los objetos de dominio en objetos persistentes. Esto se hace para no acoplar los objetos de dominio con cuestiones de base de datos. Para esto se crea un objeto genérico (la clase abstracta Entity) que tiene adentro el identificador de bases de datos con el objetivo de crear desacoplamiento y para subir la cohesión de los objetos. Para esto hacemos que footballteam implemente Entity.

gasparoberti commented 2 years ago

Para que Entity sea abstracto y se pueda utilizar en distintas capas debemos colocarlo en la capa abstracciones. Para esto se crea una interfaz en la capa de abstracciones que posee la firma para los identificadores. Por último Entity implementa IEntity con el objetivo de que todo quede asociado con un nivel mas alto de abstracción.

gasparoberti commented 2 years ago

Se agregaron restricciones sobre los objetos genéricos (Application, Repository y DataAccess) para que solo puedan ingresar a la capa de aplicación objetos que sean de tipo IEntity.

Screenshot_195

Sabiendo los genéricos podemos saber cuáles son los atributos genéricos que necesitamos en cada capa (Id por ej.). Por ejemplo podemos buscar dentro de nuestros datos (Importar System.Linq) en la colección en memoria el objeto y según si lo encuentro o no lo elimino.

Screenshot_196

Lo mismo se aplica a todos los métodos de la clase DbContext.

gasparoberti commented 2 years ago

Por último hacemos la inyección en el repositorio de la misma manera que se hizo en la capa de aplicación. También se genera la adaptación de los métodos. Este "pasamanos" de abstracciones se hace para crear mayor desacoplamiento.

También agregamos en el startup el service.AddScoped para el contexto de la BD.

Screenshot_197

gasparoberti commented 2 years ago

Si ponemos un breakpoint podemos ver que el funcionamiento es correcto.

Screenshot_198

gasparoberti commented 2 years ago

Modificamos el get para que muestre los elementos de la lista y agregamos un método Post al controller que reciba un objeto que represente el objeto del dominio (FootBallTeamDTO)

Screenshot_199

Luego probamos el post en el Postman y vemos que es correcto el funcionamiento.

Screenshot_200

gasparoberti commented 2 years ago

Si probamos el get nos traerá una lista vacía porque cada request instancia todo de nuevo y se pierden los objetos que ya se crearon.

Para corregir esto podemos modificar la configuración en el startup para que el dbcontext tenga un addSingleton en vez de un AddScope. Esto mantiene una instancia singleton en toda la ejecución mostrando los objetos que cree en la colección de memoria.

Screenshot_201