Consideraciones previas sobre Repositoy y Unit of Work

Antes de ver cómo he realizado la implementación de Repository y Unit of Work, me gustaría comentar alguna cosa.

1. Repository

Definición

Es el intermediario entre la capa de dominio y el framework de persistencia; es una colección de objetos del dominio en memoria sobre los que podemos hacer acciones CRUD (siempre en memoria) o consultas

¿Qué nos aporta utilizar Repositories?
Bajo mi modesta opinión, tenemos tres ventajas:

• Reducción de duplicidad de consultas.
• Nos desacopla de los frameworks de persistencia
• Nos facilita los test

1. Unit of Work

Definición
Se encarga de realizar la persistencia de los objetos modificados en memoria.


Hay gente que considera que no es necesario reimplementar este patrón utilizando Entity Framework porque éste ya lo es. Es cierto que lo implementa, pero por si solo, creo que tiene algunos puntos que no me convencen

Con EF tenemos DbSet que actuan como Repository; en DbSet tenemos los mismos métodos que tenemos en un Repository (Add, Remove, ....)
También es cierto que tenemos DbContext que implementa Unit of Work y que coordina las actualizaciones de los objetos modificados en memoria (DbSet)
Pero con dbSet:

• No evitamos repetir consultas; si queremos saber los movimientos de un usuario entre un rango de fechas, tenemos que repetir la consulta tantas veces como la necesitemos.... a no ser que lo encapsulemos en una clase (Repository?) o implementemos cualquier otra solución
• No nos desacoplamos del framework de persistencia. Bueno, esta parece clara.

y con DbContext, la dependencia con EF es evidente.

Por eso creo que EF por si solo no implementa este patrón y por eso he decidido hacer mi implementación que veremos en la próxima entrada.