Why use Repository Pattern or please explain it to me?

Question

I am learning repository pattern and was reading Repository Pattern with Entity Framework 4.1 and Code First and Generic Repository Pattern - Entity Framework, ASP.NET MVC and

Answer 1

When you are designing your repository classes to look alike domain object, to provide same data context to all the repositories and facilitating the implementation of unit of work, repository pattern makes sense. please find below some contrived example.

  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();
  }
}

Answer 2

One thing is to increase testability and have a loose coupling to underlying persistance technology. But you will also have one repository per aggregate root object (eg. an order can be an aggregate root, which also have order lines (which are not aggregate root), to make domain object persistance more generic.

It's also makes it much easier to manage objects, because when you save an order, it will also save your child items (which can be order lines).

Answer 3

This picture makes it easy to understand

Answer 4

The same reason you don't hard code file paths in your app: loose coupling and encapsulation. Imagine an app with hard coded references to "c:\windows\fonts" and the problems that can cause. You shouldn't hard code references to paths so why should you hard code references to your persistence layer? Hide your paths behind config settings (or special folders or whatever your os supports) and hide your persistence behind a repository. It will be much easier to unit test, deploy to other environments, swap implementations, and reason about your domain objects if the persistence concerns are hidden behind a repository.

Answer 5

It's also an advantage to keep your queries in a central place; otherwise your queries are scattered around and are harder to maintain.

And the first point you mention: "To hide EF" is a good thing! For instance, saving logic can be hard to implement. There are multiple strategies that apply best in different scenarios. Especially when it comes to saving entities which also have changes in related entities.

Using repositories (in combination with UnitOfWork) can centralize this logic too.

Here are some videos with a nice explanation.

Answer 6

Repository systems are good for testing.

One reason being that you can use Dependency Injection.

Basically you create an interface for your repository, and you reference the interface for it when you are making the object. Then you can later make a fake object (using moq for instance) which implements that interface. Using something like ninject you can then bind the proper type to that interface. Boom you've just taken a dependence out of the equation and replaced it with something testable.

The idea is to be able to easily swap out implementations of objects for testing purposes Hope that makes sense.