3-persistencia-ef

[gasparoberti]

Se agrega la persistencia utilizando entity framework extendiendo el repositorio y reemplazando la colección de memoria por un proveedor de datos (EF) con Sql Server.

[gasparoberti]

En los proyectos DataAccess y ... agregamos los siguientes paquetes desde el adm de paquetes de nuggets

Microsoft.EntityFrameworkCore.SqlServer Microsoft.EntityFrameworkCore.Tools

Verificar versión de .net para instalar los paquetes compatibles para esa versión porque puede haber errores.

dotnet --version ->devuelve la versión, de acuerdo a eso es la versión de los paquetes que debemos instalar.

con dotnet build podemos verificar si está todo correcto.

[gasparoberti]

En appsettings.json configuramos el string de conexión para nuestra base de datos.

"ConnectionStrings": { "DefaultConnection": "Data Source=DESKTOP-C8449RA\SQLEXPRESS;Initial Catalog=ApiRest;Integrated Security=true;" }

En sqlserver creamos la bd ApiRest.

[gasparoberti]

Se refactorizó la clase DbContext para utilizar EF en vez de la colección de memoria con la que estábamos trabajando.

1- Modificamos la restricción del template T agregando la palabra class.

2- Creamos un objeto que nos permite usar EF (DbSet).

3- Corregimos todas las apariciones de la colección de memoria para utilizar EF.

[gasparoberti]

En la capa de acceso a datos creamos otra capa que es el proveedor o el contexto de EF (ApiDbContext). Esta clase implementa una clase abstracta de EF (DbContext).

Se crea un DbSet por cada uno de los objetos de dominio que se quieren persistir. Esto permite crear el contexto de bd y permite tener un acceso a cada una de las tablas que se van a crear cuando se ejecute la aplicación.

Se crea el contexto de bd con EF. Se sobreescribe la operación OnModelCreating (permite configurar que queremos que sucede cuando se crea el modelo de bd al ejecutar la app y al crear la migración del modelo de objetos al modelo de datos).

Debe ignorar la clase Entity que se creó anteriormente para evitar que se cree una tabla Entity en la bd.

En la clase dbcontext se recibe por el constructor la instancia de apidbcontext en donde está el proveedor de datos configurado. Por lo tanto ese contexto se inyecta en la capa dbcontext genérica.

Por último se setea en la lista de items y se deja disponible para utilizar todo lo que se necesita para el contexto separando las clases del contexto.

En caso de que se quiera cambiar el contexto de bd y usar uno diferente se crea un contexto diferente y se lo cambia en la inyección de dependencias.

[gasparoberti]

Se realiza el refactoring para poder usar el contexto dbcontext genérico con EF.

[gasparoberti]

En startup se realiza la configuración para poder inyectar el contexto apidbcontext en donde sea necesario (la clase dbcontext genérica).

[gasparoberti]

Se crea la migración inicial en donde se le indica a EF que cree un esquema de datos a partir de lo que está definido en el contexto apidbcontext.

Esto se hace desde la consola estando parados sobre la carpeta WebApi pero antes debe estar agregado el paquete Tools (Recordar de que el paquete se debe instalar en el proyecto WebApi y en la versión correspondiente al .net instalado, 5.04 en este caso).

dotnet ef migrations add "Migración Inicial"

la migración es un grupo de comandos sql que se ejecutan para actualizar la bd.

OBSERVACIÓN: no se por qué no funciona el migrations si solo instalo el el paquete tools en un proyecto específico. Por lo tanto lo que hice para solucionar esto es instalar Tools en todos los proyectos (la versión 5.04). De esa manera si funcionó el comando migrations.

Por último corremos el comando dotnet ef database update para que actualice la bd.

Cada vez que se haga un cambio en la clase se debe hacer una nueva migración y actualizar la bd. Por ejemplo si agregamos el atributo Manager en la clase FootballTeam. Para reflejar este cambio en la bd hacemos una nueva migración un nuevo update.

[gasparoberti]

Por último hay que volver la conf del dbcontext a AddScoped en vez de AddSingleton.

Y se actualiza el DTO de footballteam para reflejar el agregado del Manager.

Y mapear el Manager en el endpoint del controller.

[gasparoberti]

Si ejecutamos la app se verifica que funciona correctamente. Desde Postman se crearon dos teams mediante el post y si enviamos el request get podemos obtener los dos teams que se crearon.