Why repository pattern is extensively used in entity framework as though it is complex?

Question

I am creating a demo project which contains crud operations using a repository pattern and dependency injection.

This is my structure:

Approach 1 (very popular, used by many developers)

My repository interface:

public partial interface IRepository<T>
{
    void Insert(T entity);
}

My service layer:

public partial interface IEmployeeService
{
    void InsertCategory(EmployeeMaster employeeMaster);
}

My class which will implement that interface (service):

public partial class EmployeeService : IEmployeeService
{
    private readonly IRepository<EmployeeMaster> _employeeMasterRepository;

    public EmployeeService(IRepository<EmployeeMaster> employeeMasterRepository)
    {
         this._employeeMasterRepository = employeeMasterRepository;
    }

   public virtual void InsertCategory(EmployeeMaster employeeMaster)
   {
        _employeeMasterRepository.Insert(employeeMaster);
   } 

This is my controller:

public class HomeController : Controller
{
        private readonly IEmployeeService  _employeeService;

        public HomeController(IEmployeeService employeeService)
        {
            this._employeeService = employeeService;
        }

Above is the structure which I am following from Nop Commerce project (http://www.nopcommerce.com) and I think most developers now a days are following this structure only that is repository pattern and dependency injection.

Previously I was doing like Below like making one Bal(business Access layer) project in my application and then making class file in Bal and doing insert like below:

Approach 2:

public class MyBal()
{
    public void Insert()
    {
        using (MyEntities context = new MyEntities ())
        {
            var result = context.MyTable.Add(_MyTable);
            context.SaveChanges();
            return result;
        }
}

And then Calling this Method straight Away from My Mvc application like this:

[HttpPost]
public ActionResult Insert(Model M)
{
    MyBal bal = new MyBal ();
    bal.Insert();
}

So why most of the developers go on creating such a complex structure that is repository pattern.Can anybody explain me the difference between Approach 1 and Approach 2 ??

Does Approach 1 increases performance or it is just related to separation of code or better maintainability of code.

Answer 1

Many people implement a Repository on top of Entity Framework, which in itself uses the Repository Pattern. There are a few variations on reasoning behind this; the decision as to if any of these make sense is a matter of opinion.

1. It is the way Microsoft demonstrated in their tutorial series, Part 9 of 10. Because Microsoft demonstrated this pattern, it is widely accepted as a reasonable practice.

2. Separation from Entity Framework. Many people strive to separate Entity Framework from their business entities, with the idea that if they ever choose to replace Entity Framework, they can change the repository without modifying other business logic. In practice, however, you should really commit to a technology, and it's quite a bit of work to correctly separate the Entity Framework logic. In the end, you most likely end up with methods in your repository that only exist because it's the EF way of doing things, so changing to another ORM is still going to affect your business entities.

3. Generics. It is a very common practice to use Generics with the Repository Pattern, which minimize code repetition. The thought is that if you have hundreds of classes to perform CRUD operations with, a Generic Repository will be more uniform and more maintainable, but with possibly a bit less flexibility.

4. Ease of integration with Dependency Injection tools. It may be easier in some cases to work with Dependency Injection tools by using the Repository Pattern.

5. Unit Testing. This goes along with point 4, using the Repository Pattern gives you a uniform class which can easily be mocked for Unit Tests.

This is by no means an exhaustive list, and there are just as many reasons to disagree with each point as to agree with them, but this is my observations of the thought processes around this particular pattern.

As for your second question, the difference between the two examples... In the first case, you have created a service and a repository, which may exist in an entirely different project or namespace from your business entity. Your business entity doesn't know about, or care about, Entity Framework. If you need to change the way that your Repository works, it should have little to no impact upon your entity, which will operate the same way it always has.

In your second case, you are directly tied to Entity Framework. This, and any other business entity must know about Entity Framework, and any changes to Entity Framework could potentially mean changing code in this or any other entity like it. With many entities, this could be a very lengthy process. Also, you cannot easily test this entity, because any tests you perform are going to cause writes to the database.