Skip to main content

Repository layer pattern

Data access abstraction: how we isolate persistence and querying from business logic.

Overview​

The repository layer provides a single place for data access. The boilerplate uses Prisma Client (generated from the orm schema) as the repository implementation. Services (see service-layer) depend on this layer for all reads and writes; they do not use the ORM directly from controllers.

Backend​

  • Technology: Prisma Client (see stack rule orm). The client is generated from the Prisma schema; PrismaService (or equivalent injectable) exposes it to the application.
  • Usage: Injected and used by the service-layer. Services call the repository (e.g. prisma.user.findMany()) and transform results with shared serialization (e.g. plainToInstance) when returning to controllers.

Implementation

The boilerplate wires Prisma via PrismaService (or direct PrismaClient injection) in a backend module. Auth persists users via the same Prisma client and User model; UsersRepository in backend/src/auth/ is a repository abstraction used by AuthService (findById, findByEmail, findOrCreateSsoUser). Other data access may live in services that inject this client directly. The generation skill ensures the orm schema, generated client, and PrismaService are in place so the service-layer can use them.

References​

  • Stack: orm (Prisma schema and client), relational-data (PostgreSQL).
  • Pattern: service-layer (consumer of repository layer).