On one hand, using design patterns is a good thing whereas on the other hand, too many patterns from the start could lead to unnecessary complexity and too much code to maintain. But some software problems and their solutions in a particular design pattern are so widely used that they have gone through good test of time. Repository pattern is one such design pattern to address common issues around data access. I am not saying that repository pattern is the best solution to the problem but it is the easiest one to get started. Repositories have their own shortcomings and come with their own problems. We would look at these and alternatives in the next chapter. For now, I want to introduce you to this pattern so that you can make an educated choice.

Repository pattern abstracts away the details of specific database operations and the persistence API used to carry out those operations. This includes infrastructure code or any interaction with the database. If I need to save an entity, I give that entity to a repository and trust that repository would save the entity in database for me. The simplest implementation of such a repository could be as follows:

public class Repository<T> where T :EntityBase<T>
{
  public void Save(T entity)
  {
    //Code to persist entity to database
  }
}

Here we have added a generic parameter T so that the Save method is typesafe. We have also added a constraint that T must be a type that inherits from EntityBase<T>. This limits the types that can be passed to domain entities only.

Right now there is nothing in the Save method. Let's try to add some code to persist the supplied entity instance to database. We would need to get hold of current session object for that. Since ISession is a capability that this class needs, we would add a constructor that takes ISession as a parameter and stores it in a field. Following is how our repository looks now:

public class Repository<T> where T :EntityBase<T>
{
  private readonly ISession session;

  public Repository(ISession session)
  {
    this.session = session;
  }

  public void Save(T entity)
  {
    session.SaveOrUpdate(entity);
  }
}

Nothing complex here. We have added a call to ISession.SaveOrUpdate and passed the supplied entity parameter. Now that our basic repository skeleton is ready, next question is where in our architecture should we add repository?

We started with EmployeeOnboardingService needing a repository. We now have a repository that we can use but can we put the repository class next to the service class? The answer is clearly a no but let's contemplate why:

Taking the preceding two points into consideration, we would need to create an interface out of the Respository<T> class so that EmployeeOnboardingService can take a dependency on that interface. We also need to move this interface into the DomainService project so that it is visible from that project. We would leave the Repository<T> in the Persistence project. Following is how the code looks now:

namespace DomainService.Capabilities
{
  public interface IRepository<T> where T : EntityBase<T>
  {
    void Save(T entity);
  }
}

namespace Persistence
{
  public class Repository<T> : IRepository<T>
  where T :EntityBase<T>
  {
    //Same as before
  }
}

Note that nothing has changed inside the class Repository<T> other than it implementing interface IRepository<T>. A shorter version of this class is presented here to save space. Also, the interface IRepository<T> is moved in a namespace DomainService.Capabilities. This is because IRepository<T> exposes a capability that domain service layer needs. This goes in line with what we discussed in the beginning. Every layer explicitly declares (using interfaces or abstract classes) the capabilities that they need someone else to provide.

We have a basic repository implementation in place which looks finished for what we need now. Let's go back to finishing the employee onboarding functionality.

A repository is the capability that our domain service class needs and it can express this requirement by taking dependency on the IRepository<T> interface from the DomainService.Capabilities namespace. We add the following code to the EmployeeOnboardingService class to satisfy the dependency requirement:

private readonly IRepository<Employee> employeeRepository;

public EmployeeOnboardingService(
IRepository<Employee> employeeRepository)
{
  this.employeeRepository = employeeRepository;
}

Here we have added a new constructor that takes a parameter of type IRepository<Employee> and saves the supplied value in a private field.

Let's use this repository capability to finish the onboarding logic:

public void Execute(Employee employee)
{
  employee.Onboard();
  employeeRepository.Save(employee);
}

A call to the IRepository<Employee>.Save method is all we need to save the employee instance. This all looks fine and dandy but what about unit of work? What about executing the whole operation as single unit? We might just implement unit of work somehow and be done with it but there are some peripheral concepts around unit of work that are interesting and important to understand.