¿Por qué usar el Patrón del Repositorio o por favor explicármelo?

No creo que debas.

El Entity Framework ya es una capa de abstracción sobre su base de datos. El contexto utiliza la unidad de patrón de trabajo y cada DbSet es un repositorio. Agregar un patrón de repositorio encima de esto lo aleja de las características de su OR.

Hablé de esto en mi entrada de blog: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern

La razón principal por la que agrega su propia implementación de repositorio es para que pueda usar inyección de dependencia y hacer que su código sea más comprobable.

EF no es muy comprobable desde el primer momento, pero es bastante fácil hacer una versión simulada del contexto de datos EF con una interfaz que se puede inyectar.

He hablado de eso aquí: http://www.nogginbox.co.uk/blog/mocking-entity-framework-data-context

Si no necesitamos el patrón de repositorio para hacer que EF sea comprobable, entonces no creo que lo necesitemos en absoluto.

Esta imagen hace que sea fácil de entender

Los sistemas de repositorio son buenos para probar.

Una de las razones es que puede usar la inyección de dependencias.

Básicamente crea una interfaz para su repositorio, y hace referencia a la interfaz para él cuando está haciendo el objeto. Luego puede hacer un objeto falso (usando moq, por ejemplo) que implementa esa interfaz. Usando algo como ninject puedes enlazar el tipo apropiado a esa interfaz. Boom que acaba de tomar una dependencia de la ecuación y lo reemplazé con algo comprobable.

La idea es poder intercambiar fácilmente implementaciones de objetos con fines de prueba Espero que tenga sentido.

También es una ventaja mantener sus consultas en un lugar central; de lo contrario, sus consultas están dispersas y son más difíciles de mantener.

Y el primer punto que mencionas: "Ocultar EF" es algo bueno! Por ejemplo, guardar la lógica puede ser difícil de implementar. Hay múltiples estrategias que se aplican mejor en diferentes escenarios. Especialmente cuando se trata de guardar entidades que también tienen cambios en entidades relacionadas.

El uso de repositorios (en combinación con UnitOfWork) puede centralizar esta lógica también.

Aquí hay algunos videos con una buena explicación.

La misma razón por la que no codifica las rutas de los archivos en su aplicación: acoplamiento suelto y encapsulación. Imagine una aplicación con referencias codificadas a "c:\windows\fonts" y los problemas que pueden causar. No debe hacer referencias de código duro a las rutas, así que ¿por qué debería hacer referencias de código duro a su capa de persistencia? Oculte sus rutas detrás de los ajustes de configuración (o carpetas especiales o lo que soporte su sistema operativo) y oculte su persistencia detrás de un repositorio. Será mucho más fácil para realizar pruebas unitarias, implementar en otros entornos, intercambiar implementaciones y razonar sobre los objetos de dominio si las preocupaciones de persistencia están ocultas detrás de un repositorio.

Cuando está diseñando sus clases de repositorio para que parezcan objeto de dominio, para proporcionar el mismo contexto de datos a todos los repositorios y facilitar la implementación de la unidad de trabajo, el patrón de repositorio tiene sentido. a continuación encontrará un ejemplo artificial.

  class StudenRepository
  {
     dbcontext ctx;
     StundentRepository(dbcontext ctx)
     {
       this.ctx=ctx;
     }
     public void EnrollCourse(int courseId)
     {
       this.ctx.Students.Add(new Course(){CourseId=courseId});
     }
  }

  class TeacherRepository
  {
     dbcontext ctx;
     TeacherRepository(dbcontext ctx)
     {
       this.ctx=ctx;
     }
     public void EngageCourse(int courseId)
     {
       this.ctx.Teachers.Add(new Course(){CourseId=courseId});
     }
  }

  public class MyunitOfWork
  {
     dbcontext ctx;
     private StudentRepository _studentRepository;
     private TeacherRepository _teacherRepository;

     public MyunitOfWork(dbcontext ctx)
     {
       this.ctx=ctx;
     }

    public StudentRepository StundetRepository
    {
       get
       {       
             if(_studentRepository==null)
                _stundentRepository=new StundetRepository(this.ctx);

            return _stundentRepository;    
       }
    }

    public TeacherRepository TeacherRepository 
    {
       get
       {       
             if(_teacherRepository==null)
                _teacherRepository=new TeacherRepository (this.ctx);

            return _teacherRepository;    
       }
    }

    public void Commit()
    {
         this.ctx.SaveChanges();
    }
  }

//some controller method
public void Register(int courseId)
{
  using(var uw=new MyunitOfWork(new context())
  {
    uw.StudentRepository.EnrollCourse(courseId);
    uw.TeacherRepository.EngageCourse(courseId);
    uw.Commit();
  }
}

Sé que es malo proporcionar enlaces en respuesta aquí, sin embargo quería compartir el video que explica varias ventajas de Patrón de repositorio cuando se utiliza con Entity framework. A continuación se muestra el enlace de youtube.

Https://www.youtube.com/watch?v=rtXpYpZdOzM

También proporciona detalles sobre cómo implementar el patrón de repositorio correctamente.