Design Patterns - Repository Pattern

The repository pattern is a design pattern to encapsulate the methods to access to a data source and access to them from any layer using Inversion of Control (IoC).

It provides better maintainability, testability, security, and decoupling from the persistence method.

Table of Contents

1. Characteristics of the Repository pattern
2. Example of the Repository pattern in C# using Entity Framework Core
3. Example of the Repository pattern in TypeScript using MikroORM

Characteristics of the Repository pattern

• The repository methods receives (as parameters) and returns Domain layer objects such as Aggregate Roots, Entities or Value Objects.
• The query methods such as get or find are asynchronous and return promises, which means that the database is instantly queried.
• The data manipulation commands such as add, update or delete are not asynchronous, because these commands are not going to be applied in the database automatically, but rather they are accumulate in the same transaction, and then they are applied using the Unit of Work pattern.

The repository pattern can be splitted into:

• Generic repository.
• Specialized repository.

Generic repository

• The interface of the generic repository is stored in the Domain layer.
• Generic repositories should not be implemented, but the specialized repositories, unless it is implemented in an abstract class.
• It is not mandatory to have a generic repository as long you use the specialized ones.

Specialized repository

• The interfaces of the specialized repositories are stored in the Domain layer.
• The implementations of the specialized repositories are stored in the Infrastructure layer and you can use a database driver or an ORM.
• Can extend from the generic repository.
• Each Aggregate has at least one specialized repository.

Example of the Repository pattern in C# using Entity Framework Core

Example of the generic repository interface in C#

public interface IRepository<T> where T : IAggregateRoot
{
  IImmutableList<T> FindAll();

  T Find(Guid id);

  IImmutableList<T> Where(Expression<Func<T, bool>> predicate);
}

About this code snippet:

• T extends from IAggregateRoot, so it forces the generic repository to work with Aggregate Roots instead of Entities.
• Methods don’t return IQueryable, but must materialize the query results before returning them.
• The methods FindAll and Where return IImmutableList.

Example of the specialized repository interface in C#

public interface IUsersRepository : IRepository<User>
{
  void Add(User user);

  void Remove(User user);
}

About this code snippet:

• In this example the entity User can be created and removed, so the specialized repository has methods for that.

Example of the implementation of the specialized repository in C# using Entity Framework Core

public sealed class UsersRepository : IUsersRepository
{
  private DbSet<User> _dbSet { get; }

  public UsersRepository(ApplicationDbContext context)
  {
    this._dbSet: context.Set<User>();
  }

  public IImmutableList<User> FindAll()
  {
    return this._dbSet.ToImmutableList();
  }

  public User Find(Guid id)
  {
    return this._dbSet.Find(id);
  }

  public IImmutableList<User> Where(Expression<Func<User, bool>> predicate)
  {
    return this._dbSet.Where(predicate).ToImmutableList();
  }

  public void Add(User user)
  {
    this._dbSet.Add(user);
  }

  public void Remove(User user)
  {
    this._dbSet.Remove(user);
  }
}

About this code snippet:

• It extends from the specialized repository.
• It requires DbContext in its constructor arguments (Which is injected with dependency injection) but just uses DbSet<User> from it.
• DbSet<User> is already a repository provided by Entity Framework Core, so our repository will be just a thin layer to hide all the methods from DbSet<User> and the implementation of the specialized repository methods.
• To materialize the query results we can use the namespace System.Linq to use extension methods such as ToArray(), ToList(), or ToImmutableList() using the namespace System.Collections.Immutable.

Example of the Repository pattern in TypeScript using MikroORM

Example of the generic repository interface in TypeScript

interface Repository<T extends AggregateRoot> {
  getAll(): Promise<T[]>;

  getOne(id: UniqueId): Promise<T>;

  add(t: T): void;

  update(t: T): void;
}

About this code snippet:

• The generic T extends from AggregateRoot, so it forces the generic repository to work with Aggregate Roots instead of Entities.
• The method getOne has a Value Object as parameter.

Example of the specialized repository abstract class in TypeScript

abstract class UserRepository implements Repository<User> {
  abstract getAll(): Promise<User[]>;

  abstract getOne(id: UniqueId): Promise<User>;

  abstract add(user: User): void;

  abstract update(user: User): void;

  abstract delete(id: UniqueId): void;
}

About this code snippet:

• In this example the Aggregate Root User can be deleted, so the specialized repository has a method for that action, otherwise it would not have them.

Example of the implementation of the specialized repository in TypeScript

For this example I am using MikroORM:

MikroORM is an ORM for JavaScript and TypeScript that allows handling transactions automatically, it will be useful to group the repository actions in a transaction and then apply it on the database using the Unit of Work pattern.

But before implementing the repository pattern, we must create the MikroORM entity, this is an Infrastructure layer entity, so it is different from the Domain layer entity and its only function is to be a schema for the persistence of the data in the database.

import {
  Entity,
  EntityRepositoryType,
  PrimaryKey,
  Property,
  SerializedPrimaryKey,
  Unique,
} from '@mikro-orm/core';
import { ObjectId } from '@mikro-orm/mongodb';
import { UserRepositoryMongoDb } from '../repositories';

@Entity({ collection: 'users' })
export class UserEntity {
  [EntityRepositoryType]?: UserRepositoryMongoDb;

  @PrimaryKey()
  _id: ObjectId;

  @SerializedPrimaryKey()
  id!: string;

  @Unique()
  @Property()
  email: string;
}

In a MikroORM entity you need to explicitly declare the repository name, in this example is UserRepositoryMongoDb.

Now that MikroORM knows with which entity it is going to work, we can write the repository implementation:

import {
  EntityData,
  EntityRepository,
  MikroORM,
  Repository,
} from '@mikro-orm/core';
import { UserEntity } from '../entities';

@Repository(UserEntity)
export class UserRepositoryMongoDb
  extends EntityRepository<UserEntity>
  implements UserRepository
{
  constructor(private readonly orm: MikroORM) {
    super(orm.em, UserEntity);
  }

  async getOne(id: UniqueId): Promise<User> {
    const userEntity: await this.findOne(id);
    if (!userEntity) return null;
    const user: userEntityToUser(userEntity);
    return user;
  }

  async getAll(): Promise<User[]> {
    const usersEntities: await this.findAll();
    const users: usersEntities.map((u) => userEntityToUser(u));
    return users;
  }

  add(user: User): void {
    const newValues: EntityData<UserEntity>: {
      id: user.id,
      email: user.email,
    };
    const newUserEntity: this.create(newValues);
    this.orm.em.persist(newUserEntity);
  }

  update(user: User): void {
    const userEntityFromDb: this.getReference(user.id);
    const newValues: EntityData<UserEntity>: {
      email: user.email,
    };
    this.orm.em.assign(userEntityFromDb, newValues);
  }

  delete(id: UniqueId): void {
    const userEntity: this.getReference(id);
    this.remove(userEntity);
  }
}

About this code snippet:

• MikroORM is injected into the constructor using dependency injection.
• Since the repository pattern must return the Domain layer user, the data obtained from the database must first be mapped, for which in this example the userEntityToUser function is being used.
• The MikroORM getReference function allows to obtain a reference of the entity, so you can work with the entity without first consulting it in the database.