Implementing UnitOfWork And Repository Pattern

Repository pattern is extensively used in Web API projects. In fact, it is a very popular architectural design pattern for desktop applications. There is another concept called ‘UnitOfWork’ which works with the repository pattern. Here, many of us make small mistakes while implementing UnitOfWork. Today, in this article, I will show you a nice way to implement ‘UnitOfWork’ with ‘Repository Pattern’. To explain the whole thing, we will make a very small Web API solution step by step. Also, I will explain a few tricks and tweaks that I personally do while designing any solution. Let’s get started.

Step 1 - Create a solution and add basic components

• I have created a basic Web API project and added a few layers to the solution.
  
  
  
  
• UnitOfWorkRepositoryPatternDemo is the standard WebAPI project.
• *.BusinessLogic is the layer that contains all the business logics.
• *.Data is the layer to keep the edmx.
• *.Models layer is the place for all the model classes. Each model class generally contains at least all the properties that are present in the corresponding entity class generated by EF.
• *.Repository is the main component to focus on in this article. I will explain this layer in greater details.

Step 2 - Implement a repository layer

• Repository layer will look like given below.
  
  
• First, create the IRepository interface inside ‘/Shared’ folder. I name it shared because this contains shared interfaces which can be shared across for Mocking.
  
  
• The code for IRepository.cs will look like this.
  

  public interface IRepository<T> where T : class
      {
          // To get single item by its id
          T Get(object id);
  
          // To get all items
          IEnumerable<T> GetAll();
  
          // To search a set of items by passing expression as parameter
          IEnumerable<T> Find(Expression<Func<T, bool>> predicate);
  
          // To add a single item
          void Add(T entity);
  
          // To update an item
          void Update(T entity);
  
          // To add a set of entities
          void AddRange(IEnumerable<T> entities);
  
          //***
          // Returns result as Querayable such that you can apply more logic
          // on top of it
          IQueryable<T> Query(Expression<Func<T, bool>> predicate);
  
          void Remove(T entity);
          void RemoveRange(IEnumerable<T> entities);
      }

• Carefully look at the method ‘Query’. This is the tweak I use for making it more flexible at the business layer. This method takes an expression as an argument. Please look at the below code block which is the implementation of this interface.
  
  Repository.cs
  

  public abstract class Repository<T> : IRepository<T> where T : class
      {
          protected readonly DbContext _context;
  
          public Repository(DbContext context)
          {
              _context = context;
          }
  
          public T Get(object id) => _context.Set<T>().Find(id);
  
          public IEnumerable<T> GetAll() => _context.Set<T>().ToList();
  
          public IEnumerable<T> Find(Expression<Func<T, bool>> predicate)
          {
              return _context.Set<T>().Where(predicate);
          }
  
          public void Add(T entity) => _context.Entry<T>(entity).State = EntityState.Added;
  
          public void Remove(T entity)=> _context.Entry<T>(entity).State = EntityState.Deleted;
  
          public void Update(T entity)=> _context.Entry<T>(entity).State = EntityState.Modified;
  
          public void AddRange(IEnumerable<T> entities)
          {
              foreach (var entity in entities)
                  _context.Entry<T>(entity).State = EntityState.Added;
          }
  
          public void RemoveRange(IEnumerable<T> entities)
          {
              foreach (var entity in entities)
                  _context.Entry<T>(entity).State = EntityState.Deleted;
          }
  
          public IQueryable<T> FindAsQueryable()=> _context.Set<T>().AsQueryable<T>();
  
          public IQueryable<T> Query(Expression<Func<T, bool>> predicate)
          {
              return _context.Set<T>().Where(predicate).AsQueryable();
          }
  
  }

• Please note, since Repository is a base class, I have made it abstract such that it can’t be instantiated separately.
• This implementation is pretty straightforward. The DbContext class is present in System.Data.Entity namespace.
• IEmployeeRepository looks like this.
  

  public interface IEmployeeRepository : IRepository<Employee>
      {
      }

• Similarly EmployeeRepository looks like this.
  

  public class EmployeeRepository : Repository<Employee>, IEmployeeRepository
      {
          public EmployeeRepository(DbContext _context) :
              base(_context)
          {
          }
      }

• Our Employee repository basic implementation is ready. The UnitOfWork is to unify all the repositories. It’s the main gateway to repositories. Let’s see how.

Step 3 - Implement UnitOfWork

• First, have a look at the IUnitOfWork interface. It’s very simple.
  

  public interface IUnitOfWork : IDisposable
      {
          IEmployeeRepository Employees { get; }
          int Complete();
          int Complete(bool usingTransaction);
          IUnitOfWork New();
      }

• Once you see the implementation of IUnitOfWork, you will get the flavor of it.
  

  public class UnitOfWork : IUnitOfWork
      {
          private DbContext _context = null;
          private readonly Type ContextType;
          public UnitOfWork()
          {
              // Store the type
              ContextType = typeof(Data.EF.EmployeeDbEntities);
          }
  
          private DbContextTransaction BeginTransaction()
          {
              return _context.Database.BeginTransaction();
          }
  
          public IEmployeeRepository Employees
          {
              get
              {
                  return new EmployeeRepository(_context);
              }
          }
  
          public int Complete()
          {
              return _context.SaveChanges();
          }
  
          public int Complete(bool usingTransaction)
          {
              if (!usingTransaction)
                  return Complete();
  
              int status = -1;
              using (var ts = _context.Database.BeginTransaction())
              {
                  try
                  {
                      status = _context.SaveChanges();
                      ts.Commit();
                  }
                  catch (Exception)
                  {
                      ts.Rollback();
                      throw;
                  }
              }
              return status;
          }
  
          public void Dispose()
          {
              if (_context != null)
                  _context.Dispose();
          }
  
          public IUnitOfWork New()
          {
              _context = null;
              TryCreateContext();
              return this;
          }
  
          void TryCreateContext()
          {
              if (ContextType == default(Type))
                  throw new Exception("Context type Unknown");
  
              if (_context == null)
                  _context = Activator.CreateInstance(ContextType) as DbContext;
          }
  }

• Have a closer look. The constructor of UnitOfWork stores the type of DbContext instead of a new instance of DbContext. This is the tweak I apply to improve the performance. The reason is that when the EF DbContext constructor is invoked, there are many heavy sub-operations which happen behind the scenes. Also, there might be some business layer calls that might not need to access UnitOfWork. This thing will be clear once we look into the business logic layer.
  
  
• Check the New() method which returns an instance of IUnitOfWork. This method actually creates an object of the type that we stored during construction. TryCreateContext() shows how it creates an object from the type using reflection. We will get to know the real benefit of it in the business layer.

Step 4 - Business layer implementation

• In business layer, I have created a base class.
  

  public abstract class BaseLogic
      {
          protected readonly IUnitOfWork unitOfWork;
  
          public BaseLogic(IUnitOfWork unitOfWork)
          {
              this.unitOfWork = unitOfWork;
          }
  }

• Each business logic class will inherit from this base class.
• Now let’s check the implementation of EmployeeLogic.cs
  

  public class EmployeeLogic : BaseLogic, Shared.IEmployeeLogic
      {
          public EmployeeLogic(IUnitOfWork uow) : base(uow)
          {
          }
  
          public List<Employee> GetEmployees()
          {
              using(IUnitOfWork uow = base.unitOfWork.New())
              {
                  return uow.Employees.GetAll()
                      .Select(x => new Employee
                      {
                          Id = x.ID,
                          Name = x.Name
                      }).ToList();
              }
          }
  
          public Employee SaveEmployee(Employee model)
          {
              var employeeEntity = new Entity.Employee() { Name = model.Name };
  
              using(IUnitOfWork uow = base.unitOfWork.New()) {
  
                  uow.Employees.Add(employeeEntity);
                  if(uow.Complete()>0)
                  {
                      model.Id = employeeEntity.ID;
                      return model;
                  }
              }
              throw new Exception("Operation failed");
          }
  
          public void DoSomethingElseThatDoesntUseUnitOfWork()
          {
  
          }
      }

• Just see, the constructor of EmployeeLogic is dependency injected with IUnitOfWork. And that has been passed to the base. In GetEmployees() and SaveEmployee(…) methods, a new UnitOfWork instance is created by base.unitOfWork.New() method. Thus, the object of UnitOfWork will be created only when you need it; you claim it. If you have any other method in a business layer which doesn’t make use of UnitOfWork object, it won’t create an unnecessary object while injecting dependency through the constructor.
• Also, another benefit is, you can happily mock IUnitOfWork and inject it into business class. Thus, it improves testability and optimizes performance.
• Note: dependency injection is not explained in this article since my main objective was to explain UnitOfWork and Repository pattern.
• I am attaching the sample code as a zip. Please leave your questions in the comments section if you have any. Happy learning!